- Station name: non null UTF-8 string of min length 1 character and max length 100 characters
- Temperature value: non null double between -99.9 (inclusive) and 99.9 (inclusive), always with one fractional digit
* Implementations must not rely on specifics of a given data set, e.g. any valid station name as per the constraints above and any data distribution (number of measurements per station) must be supported
The README says max length 100 bytes, which I suppose we can (?) assume are octets. Also, it mentions that you can assume the station string does not contain the separator ';'.
I guess the station string is also supposed to be free of control characters like newlines, though spaces are allowed. This, however, is not stated.
This compilation step is only required once when you release your tool. The resulting binary is then providing fast startup and low memory footprint whenever users invoke your tool. So, yes, it is a real win if your tool gets used more than once.
Or use like lots of other languages that provide all these "wins" without having to provide justifications like "only for release build and if your tool gets used more than once".
I can't really think of a language that I'd rather use than Clojure right now. So, I'd have to get these "wins" I'd have to switch to working with a language I enjoy less.
Yes. Sulong assumes that at least the LLVM bitcode including debug information is available. It does not work with third party machine code binaries where no source information is available.
The idea of Truffle language interoperability is to avoid switching the representation at the language boundary. Objects carry their type information with them that includes the semantics on how to access their properties. This also allows Truffle to fake up the existence of an object without actually performing allocations (e.g., a table in raw buffer format can be interpreted as an array of objects). This clear separation of logical and physical layout enables efficient data representation in the context of higher level languages that typically suffer from pointer chasing and object header overheads.
Right, and my point is that this won't work unless you dictate a common memory layout for all Truffle objects. And if you do that, then you lose the ability to make trade-offs about object representation that depend upon access patterns that only the programmer can know. The whole reason we have different programming languages is because not all domains of computation face the same trade-offs.
It works without common memory layout between Truffle languages. It even simplifies the ability to use diverse physical memory layouts within the same language. The programmer specifies the logical layout based on the semantics of a language. The runtime decides how to map this logical layout onto the physical hardware. It can take into account the trade-offs the programmer decided to choose.
Right, and my point is that the reason people continue to use C++ or Rust over JVM languages is because there are some use-cases where the JVM's decision about how to map the logical layout onto physical memory causes unacceptably high memory usage and/or cache misses, or prevents them from taking advantage of clever serialization formats (Cap'n Proto, for example, loses much of its performance benefits on the JVM without the use of sun.misc.unsafe). Will Truffle allow the programmer to override Graal's decisions on this and manually specify memory layout? And if so, how are conversions between different language formats specified?
If you already buy the JVM's premise of "just let the compiler do it, we'll figure out the most efficient representation", then this is a non-issue. But there are still programmers out there who believe that Rust or C++ or Go or CPython or whatever presents a better memory layout for the tasks that they wish to accomplish, or language designers who think they can do better than all of the above, and these are the users that Graal+Truffle is trying to win over. What's the story for them?
The default when running static languages like C++ or Rust or Go via Sulong is to stick to the memory layout chosen by the programmer. There is no conversion to typical JVM memory layouts. Nor does running on the JVM has major restrictions for the framework (we are working on a version that does not run on the JVM in the SubstrateVM project). What Graal+Truffle allows is for library writers and language designers to invent new representations without any restrictions on the layout and have them interact with the rest of the system. We want programmers to use the best language for the task. And even combine multiple languages within one program. Foreign objects can be passed around freely as parameters and local variables, but there are restrictions when building combined data structures - e.g., if you have a highly optimized native data structure, it is not possible to install a pointer to a JavaScript object in it without performance loss.
Interesting. So, if I'm understanding this correctly - Truffle allows a language designer to specify a certain logical layout for data structures, along with hints for how this will get converted to a physical memory layout. Language implementors also get the full power of Graal for lowering their AST to machine code and other compiler tasks. On cross-language boundaries, it generates automatic accessors for other languages to access that data, using the logical layout to identify how particular fields need to be pulled out and manipulated, but not requiring that the full data structure be converted across the foreign-call boundary. One consequence of this is that nesting & embedding of data structures may require an explicit conversion, since if an object is a hashtable in Javascript but a packed series of fields in C, it's obviously not going to fit.
Sorta like SWIG++? If you could do SWIG but never require that an end-user write a typemap or debug a crash themself, there'd probably be a big market for that.
Agreed that this is only research prototype with significant limitations at the moment. Dynamic changes to the graph should however be something in particular a dynamic optimization framework like Truffle can cope with.
The problem is that nobody trusts Oracle. Have a look at what happened to Google. Their code didn't even originate from Oracle and they still got sued for made-up, bullshit reasons.
It of course sucks for those who invested their time in hacking the Oracle stack, but I think many people these days outside the Oracle bubble see Oracle as a dead-end.
Most people don't have a war chest full of money to hire the best lawyers like Google to protect them against baseless lawsuits.
Anyway, even from a technical point of view, things like Graal and Truffle are terrible workarounds and I prefer just fixing the things which are broken in the first place. Seeing that this will never happen at Oracle, I'll just work on code were the maintainer/owners are not so openly hostile.
But you see, this is exactly the wrong kind of conversation. You can't say "nobody trusts Oracle" while Oracle is bigger and more profitable than Google, and while the majority of important software worldwide is built on Oracle technology. Oracle won't pay attention to this kind of statement because it's obviously false. The truth is that most companies do trust Oracle.
What we can and should say is that Oracle is losing the trust of the Silicon Valley startup crows, and that this is a very important population segment. It's like a candidate being elected but gradually losing the young vote – it's a bad sign that Oracle would do well to consider.
