121–130 of 138 posts
Earlier quoted context omitted.
You can write one in X11 if you like, if you make people install Xquartz.
Is there example how to do that on mac. Just happy to have an old emu ibm 5100 sun x program. Wonder I need to boot up a vm or can try squartz …
Or install from the project homepage [1]. Then just launch the X11 app. Note that it does require the application to be built for Mac - it’s not an emulator, just an implementation of the X11 APIs.
Uses under 1.5 MB of memory at any one time (most of it is used for drawing the window). Unfortunately there is no screenshot and I have no access to a Mac at the moment, but if View.c is where things actually happen, that is a huge amount of memory just for a (resizeable?) window with a little filled rectangle in it. The memory usage of a trivial app like this should be measured in kilobytes. Comparing applications…
Here is a picture: https://cs.joshstrange.com/VSgrY06f
Earlier quoted context omitted.
In my experience, Java is a nightmare the moment you try to do anything beyond what C++ can (easily) do.
Which would be?
1) A program that copies all data from standard input to the standard output. Try to write this without Googling. Simple enough, eh?
2) A program that serves as a middleware between servers and clients, both of which are behind NATs so they connect to your middleware, using gRPC methods. Servers use gRPC streams to maintain a connection, send their ID as the first message, receive request messages, and send reply messages. Clients send ID and request in a message, and receive reply message.
I hope you're willing to show me how wrong I am by writing the code :)
Earlier quoted context omitted.
Which would be?
Ok, here are two examples on the top of my head, of fairly trivial programs that are a pain to do right in Java. 1) A program that copies all data from standard input to the standard output. Try to write this without Googling. Simple enough, eh? 2) A program that serves as a middleware between servers and clients, both of which are behind NATs so they connect to your middleware, using gRPC methods. Servers use gRPC s…
public class Test {
public static void main(String[] args) {
System.in.transferTo(System.out);
}
}
Never versions of Java are quite pleasant to work with. There are a lots of quality-of-life improvements (switch expression, multi-line string literals, string templates (currently in preview), lots of useful stdlib APIs), as well as quite fundamental additions like Loom.
edit: formatting, explanations
It seems that the code is the result of the ObjC preprocessor. :-)
https://clang.llvm.org/docs/ClangCommandLineReference.html#c...
Earlier quoted context omitted.
Ok, here are two examples on the top of my head, of fairly trivial programs that are a pain to do right in Java. 1) A program that copies all data from standard input to the standard output. Try to write this without Googling. Simple enough, eh? 2) A program that serves as a middleware between servers and clients, both of which are behind NATs so they connect to your middleware, using gRPC methods. Servers use gRPC s…
1 is really trivial and took me like 5 seconds to write: public class Test { public static void main(String[] args) { System.in.transferTo(System.out); } } 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. Never versions of Java are quite pleasant to work with. There are a lots of quality-of-life improvements (switch expression, multi-line st…
Ok, that's really convenient :) I suppose it would be much harder to do it without the transferTo function, but that would be beyond the point. I'll instead focus on the example 2.
> 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs.
The gRPC protocol here is only an example. Feel free to use any protocol you like. As a counter-example, here's a TCP version in https://gist.github.com/paskozdilar/6871fef7b0b245a0846bd27e...
> Never versions of Java are quite pleasant to work with
I know this is a typo, but you accidentally wrote something completely true :')
Earlier quoted context omitted.
1 is really trivial and took me like 5 seconds to write: public class Test { public static void main(String[] args) { System.in.transferTo(System.out); } } 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. Never versions of Java are quite pleasant to work with. There are a lots of quality-of-life improvements (switch expression, multi-line st…
> System.in.transferTo(System.out); Ok, that's really convenient :) I suppose it would be much harder to do it without the transferTo function, but that would be beyond the point. I'll instead focus on the example 2. > 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. The gRPC protocol here is only an example. Feel free to use any protocol yo…
I can try doing it later today, but I’m 100% sure that TCP example will look pretty much the same in Java, in terms of complexity.
> The gRPC protocol here is only an example. Feel free to use any protocol you like.
FWIW, this is a pretty huge change. gRPC is quite complex, as it includes protobuf, http/2 and its own RPC mechanism. A simple TCP protocol is peanuts compared to that.
Earlier quoted context omitted.
1 is really trivial and took me like 5 seconds to write: public class Test { public static void main(String[] args) { System.in.transferTo(System.out); } } 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. Never versions of Java are quite pleasant to work with. There are a lots of quality-of-life improvements (switch expression, multi-line st…
> System.in.transferTo(System.out); Ok, that's really convenient :) I suppose it would be much harder to do it without the transferTo function, but that would be beyond the point. I'll instead focus on the example 2. > 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. The gRPC protocol here is only an example. Feel free to use any protocol yo…
No, it would not:
public class Test {
public static void main(String[] args) throws Exception {
byte[] buf = new byte[4096];
int read;
while ((read = System.in.read(buf)) > 0) {
System.out.write(buf, 0, read);
}
}
}
Earlier quoted context omitted.
Yes, for COM programming you better switch to C++.
Even then, MFC and C++/CX were the only productive ways to use it from Microsoft SDKs. .NET isn't as convenient as VB 6 was, fully embracing COM as the VBX replacement model, technically introduced in VB5, but still some stuff was lacking. Then there is Delphi and C++ Builder. It beat me that having doubled down on COM since how Longhorn went down, and Windows team getting their way doing avoiding .NET to take over,…
Source: worked professionally for years on an MFC-based app that communicated with an out-of-process COM server which we also wrote. The COM bits sucked.