| --- Log opened Wed Apr 18 00:00:36 2018 |
| 00:14 | | himi [sjjf@Nightstar-1drtbs.anu.edu.au] has joined #code |
| 00:14 | | mode/#code [+o himi] by ChanServ |
| 00:23 | <@gnolam> | Oh FFS Qt. |
| 00:25 | <@gnolam> | So it has a standard MVC thingy for tables and lists and suchlike. |
| 00:26 | <@gnolam> | Most of them can use the same models, but some have their own specialized ones. |
| 00:27 | <@gnolam> | But they still have the same interface. |
| 00:27 | <@gnolam> | Except that they have, for no discernible reason whatsoever, decided to switch the argument order in their methods. >_< |
| 00:29 | <@TheWatcher> | Awesome |
| 00:30 | | lrvickEX89YL [vhrvnwf@Nightstar-m1c.qou.23.218.IP] has joined #code |
| 00:30 | | Kindamoody is now known as Kindamoody[zZz] |
| 00:30 | | lrvickEX89YL [vhrvnwf@Nightstar-m1c.qou.23.218.IP] has quit [Z-Lined: Killbot has judged you to be a spammer. Begone. (ID: QMQIT1WTHM)] |
| 00:31 | <&McMartin> | I wonder what this will do to Clojure startup times: http://www.graalvm.org/ |
| 00:32 | <&McMartin> | (I don't think there's much to gain from the LLVM side, honestly, beyond a cleaner integration with JVM-based FFI mechanisms) |
| 00:41 | | ekdb` [ceebhiu@Nightstar-prelmb.static.reverse-mundo-r.com] has joined #code |
| 00:41 | <&ToxicFrog> | Oooooo |
| 00:42 | | ekdb` [ceebhiu@Nightstar-prelmb.static.reverse-mundo-r.com] has quit [Z-Lined: Killbot has judged you to be a spammer. Begone. (ID: 5P4DIY3Y6W)] |
| 01:00 | | celmin|sleep_stupid_computer is now known as celticminstrel |
| 01:27 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 02:59 | | Jessikat [Jessikat@Nightstar-pp4gjl.dab.02.net] has quit [[NS] Quit: Bye] |
| 03:18 | | McMartin [mcmartin@Nightstar-rpcdbf.sntcca.sbcglobal.net] has quit [[NS] Quit: Reboot] |
| 03:22 | | McMartin [mcmartin@Nightstar-rpcdbf.sntcca.sbcglobal.net] has joined #code |
| 03:22 | | mode/#code [+ao McMartin McMartin] by ChanServ |
| 03:37 | | Degi [Degi@Nightstar-no3sid.dyn.telefonica.de] has quit [Connection closed] |
| 04:21 | | Jessikat [Jessikat@Nightstar-dt8pfi.dab.02.net] has joined #code |
| 05:17 | | Derakon is now known as Derakon[AFK] |
| 05:18 | | celticminstrel is now known as celmin|sleep |
| 05:53 | | macdjord is now known as macdjord|slep |
| 06:00 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 06:00 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 07:24 | | himi [sjjf@Nightstar-1drtbs.anu.edu.au] has quit [Ping timeout: 121 seconds] |
| 09:02 | | Kindamoody[zZz] is now known as Kindamoody |
| 09:12 | | Jessikat [Jessikat@Nightstar-dt8pfi.dab.02.net] has quit [[NS] Quit: Bye] |
| 11:33 | | Degi [Degi@Nightstar-no3sid.dyn.telefonica.de] has joined #code |
| 13:36 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 13:36 | | mode/#code [+o mac] by ChanServ |
| 13:37 | | macdjord|slep [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 14:00 | | macdjord|slep [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 14:00 | | mode/#code [+o macdjord|slep] by ChanServ |
| 14:02 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 14:48 | | Degi [Degi@Nightstar-no3sid.dyn.telefonica.de] has quit [Connection closed] |
| 15:01 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 15:55 | | Kindamoody is now known as Kindamoody|afk |
| 17:13 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 18:14 | <&jeroud> | "High-performance polyglot VM" -- I am skeptical. |
| 18:16 | <@TheWatcher> | I dunno, sounds legit to me. That's one you need to swear at in >3 languages to make it work, right? |
| 18:19 | <@gnolam> | :) |
| 18:31 | <&McMartin> | There are three possible things this seems like it could be, and only one of them is actually interesting |
| 18:31 | <&McMartin> | (a) It might be an LLVM runtime and a JVM duct-taped together, in which case, meh |
| 18:32 | <&McMartin> | (b) It might be a glue layer so that FFI between LLVM-targeted languages and JVM-targeted languages is easier/more portable, in which case, eh. That's an advance, but nobody will bother to go to the trouble when JNI is "good enough" |
| 18:32 | <&McMartin> | (c) It might render arbitrary JVM+JNI code into LLVM bitcode as a target, in which case that is a huge deal. |
| 18:33 | <&jeroud> | Neither of those address Python. |
| 18:33 | | * [R] wonders if it could run obfuscated Java |
| 18:33 | <&jeroud> | Unless they mean Jython, in which case "why bother". |
| 18:33 | <&[R]> | Or does it need to compile the source itself |
| 18:34 | <&[R]> | "The current release is based on the OpenJDK 8 and includes JavaScript (including Node.js) as a pre-installed extension language." |
| 18:34 | <&[R]> | Hmm |
| 18:34 | <&McMartin> | [R]: I would assume any technology that looks even a little like this would be operating on the level of JVM bytecode/classfiles |
| 18:34 | <&McMartin> | So it ought to run obfuscated bytecode fine; it's just more stuff to translate |
| 18:34 | <&McMartin> | Your debug info will be hot garbage though~ |
| 18:35 | <&[R]> | Yeah, I was wondering if it would be its own VM (like Parrot) or what |
| 18:35 | <&[R]> | Seems like they just use OpenJDK |
| 18:35 | <&McMartin> | jeroud: The fact that any calling into our out of the JVM ecosystem will have all the problems Jython has is the main reason I'm calling that "eh". |
| 18:35 | <&[R]> | I might poke around with it |
| 18:36 | <&McMartin> | Do give us a trip report if you do |
| 18:42 | <@ErikMesoy> | "trip" as in vacation or as in high? :P |
| 18:43 | <&McMartin> | As needed! |
| 18:44 | <&McMartin> | Huh. It looks like in the runup to the first 'official' Rasberry Pi release of RISC OS they've managed to tickle some firmware bugs in the Pi 3. |
| 18:45 | <&McMartin> | (RISC OS being the technically-still-under-development OS that originally came out on the Acorn Achimedes, and which the Pi had been made to run within a year of its launch) |
| 18:45 | <&McMartin> | "If you mean the issue where on a Raspberry Pi with gamma correction, the video stops working after a few hours, then this issue is being actively investigated – notably with the Raspberry Pi firmware developers." |
| 18:45 | <&McMartin> | I wonder if that's a quirk of their own video implementations or if Raspbian just never attempted this |
| 18:46 | <&McMartin> | this = gamma correction |
| 18:54 | <&ToxicFrog> | Looking at Graal, it looks like it's a new VM (Substrate) that can ingest JVM or LLVM bytecode, with support for R, Python, JS, etc being implemented as forks of those languages that emit SVM bytecode or something of that ilk |
| 18:55 | <&ToxicFrog> | I may experiment with the native image generation for clojure, but they note that JVM reflection has serious limitations and dynamic classloading is outright forbidden in Graal, so any use of clojure with it will have to be delicate. |
| 18:55 | <&McMartin> | That lowers my interest considerably |
| 18:55 | <&McMartin> | If dynamic classloading is outright forbidden that's all she wrote for stuff like Spring, too, isn't it? |
| 18:56 | <&[R]> | I LIFE HVE |
| 18:57 | <&McMartin> | wat |
| 18:57 | <&[R]> | Wrong window, wasn't sure where input was going. That's just junk input |
| 18:57 | <&ToxicFrog> | I have no idea what Spring is |
| 18:58 | <&ToxicFrog> | But the docs say that "Loading classes with Class.forName() or subclassing java.lang.ClassLoader to dynamically generate new bytecodes and load them; relying on classes being unloaded at run time." is "not supported, and cannot be supported" |
| 18:58 | <&[R]> | Ah, lack of reflection would kill my intended test (running Minecraft Forge) |
| 18:58 | <&ToxicFrog> | For Clojure I think this is not a dealbreaker, since clojure AOT compilation should resolve all class generation and loading at compile time for most uses |
| 18:59 | <&ToxicFrog> | And *warn-on-reflection* will tell you when it's generating reflection calls |
| 18:59 | <&ToxicFrog> | (it also looks like some stuff is more supported in native image generation, which is the thing I'm most interested in) |
| 19:00 | <&ToxicFrog> | (since clojure's third biggest pain point for me is excessive startup times) |
| 19:00 | <&McMartin> | (Yes, that is the thing I most want numbers on) |
| 19:00 | <&McMartin> | Spring is one of the heavily automated web framworks that is the ninetieth evolution away from J2EE et al |
| 19:00 | <&McMartin> | (What are the first two?) |
| 19:01 | <&ToxicFrog> | (compile-time error reporting in general, and (lack of) static type checking in specific) |
| 19:02 | <&ToxicFrog> | (the first in particular is why I am not constantly evangelizing it; clojure's error reporting, and especially it's compile-time error reporting, is awful.) |
| 19:03 | <&McMartin> | Anyway, yeah |
| 19:04 | <&McMartin> | A metric fuckton of web frameworks and component-based middleware solutions rely entirely on a combination of Class.forName() based on values read out of a specification file. |
| 19:04 | <&McMartin> | Including, AFAIK, every framework with any significant use. |
| 19:04 | <&McMartin> | Without that, Graal is a nonstarter in the back office. |
| 19:04 | | * ToxicFrog nods |
| 19:05 | <&McMartin> | Like, I'm not even sure it can run *Tomcat* |
| 19:05 | <&ToxicFrog> | I'm looking at it from the perspective of "I want to take a jar file and emit native executables" and it looks like it'd be useful there |
| 19:05 | <&McMartin> | That would solve your many pain points that Kessler had! |
| 19:06 | <&ToxicFrog> | I am less interested in "I want to embed other languages in a JVM program" but it looks like it may also be a contender in that space, and one of the examples is a REPL for #{javascript, R, python, ruby} that shares state between them and can switch languages on the fly in like 20 lines. |
| 19:06 | <&ToxicFrog> | Yes. Yes it would. |
| 19:07 | <&McMartin> | IMO that's a parlor trick, and jerith's citation of Jython is as good a piece of evidence as any as to why that should be the default attitude |
| 19:07 | <&ToxicFrog> | I have no experience with Jython whatsoever. |
| 19:08 | <&ToxicFrog> | But I think the point here is "it gives you one consistent API for embedding other languages and reading/writing their state", which is useful even if embedding all of those languages at once is not. |
| 19:08 | <&McMartin> | "You don't use it because either you might as well use CPython or you're relying on stuff nobody else will have available, so, welp" |
| 19:09 | <&ToxicFrog> | So, one of the other examples is loading and running arbitrary python and ruby libraries in Graal |
| 19:10 | <&ToxicFrog> | I don't think I understand your objection here. |
| 19:11 | <&McMartin> | "Nobody actually wanted this, so nobody uses it" |
| 19:11 | <&McMartin> | "Now you can embed something like Python in your Java!" |
| 19:11 | <&ToxicFrog> | What is "this" here? Embedding one language in another? That is trivially wanted |
| 19:11 | <&McMartin> | "Is it actually Python?" "Well, no, because you're using JVM types in the code and so it won't work anywhere else" |
| 19:12 | <&ToxicFrog> | Ok, so, the point here is that it is actually python and can load and run libraries written for cpython |
| 19:12 | <&McMartin> | "Does it give me any advantage over the 900,000 languages that compile to classfiles and that are indistinguishable from Java?" "Well, it kind of looks like Python?" |
| 19:12 | <&ToxicFrog> | So the supposed win there is "take existing python code, run it faster, and call into it from $other_language that your other existing things are written in, rather than rewriting either the python code or the thing you want to call it from" |
| 19:13 | <&ToxicFrog> | (or vice versa; presumably there are libraries in the JVM ecosystem that don't have a Python equivalent) |
| 19:13 | <&McMartin> | (Quite) |
| 19:13 | <&McMartin> | (But Jython IIRC also didn't really make classfiles the way Clojure or Groovy does) |
| 19:15 | <&ToxicFrog> | Looking at it, they say that the python implementation is still "highly experimental" but their current targets are full Python 3.7 and SciPy compatibility. |
| 19:16 | <&McMartin> | Oh yeah, I should probably formally migrate Ophis to Python 3 one of these weeks |
| 19:16 | <&ToxicFrog> | Wow github is slow today |
| 19:18 | <&ToxicFrog> | There's a lua implementation that apparently has performance on par with luajit. |
| 19:25 | <&ToxicFrog> | Poking around the docs some more, it looks like Truffle is the "language implementation" API; it emits some sort of IR that Graal ingests. So they have a JVM->GIR thinger (bypassing Truffle), and then use Truffle for everything else, including LLVM IR. |
| 19:26 | <&ToxicFrog> | So it is not rendering arbitrary JVM code into LLVMIR, it's rendering both JVM and LLVMIR into something else. |
| 19:32 | <&ToxicFrog> | So, it looks like the main use cases here are: |
| 19:33 | <&ToxicFrog> | - you have something targeting the JVM, or with a Truffle implementation, and you want a fast-starting native binary version of it |
| 19:33 | <&ToxicFrog> | - you have stuff written in two or more languages that you need to intercall, and none of them are replaceable in a way that lets you boil everything down to a single common language |
| 19:34 | <&ToxicFrog> | - you are writing software in one language supported by it (probably targeting the JVM) and want to embed another language for e.g. config files or user-supplied scripts |
| 19:35 | <&ToxicFrog> | Not having used JNI, I have no idea if the Graal API is nicer for calling into native code than JNI is, but that might also be a use case. |
| 19:40 | <&McMartin> | Having personally implemented a JNI layer for some C code last week, I can attest that JNI is sufficiently awful that you want to automate as much of the glue layer as possible, but that it is functionally no different from any other FFI where you have to tell the garbage collector things. |
| 19:41 | <&McMartin> | JNI is also very, very reflection-based, though, so that gets interesting. |
| 19:41 | <&ToxicFrog> | Ok, on my nonogram player native-image NPEs |
| 19:41 | <&McMartin> | If you have a jobject and want to read fields out of it you have to collect a jfieldid by name and then all extra work is done from that. |
| 19:42 | <&McMartin> | I'm not sure if they're counting "getfieldbyname" as reflection, but there's literally no other way to manage that in JNI. |
| 19:42 | <&ToxicFrog> | (in com.oracle.graal.pointsto.ObjectScanner.scanField) |
| 19:42 | <&McMartin> | (likewise, the INVOKEINTERFACE instruction implies at least enough reflection-adject stuff to permit the implementation of traits and possibly duck typing) |
| 19:42 | <&ToxicFrog> | And in a much smaller clojure program I had lying around (for figuring out valid Diablo 2 runewords given the contents of your inventory, IIRC) it dies with ArrayIndexOutOfBoundsException |
| 19:43 | <&ToxicFrog> | During control flow analysis, looks like |
| 19:48 | <&ToxicFrog> | So, uh, needs more worki |
| 19:48 | <&McMartin> | Sounds like |
| 19:49 | | Kindamoody|afk is now known as Kindamoody |
| 20:17 | | Degi [Degi@Nightstar-no3sid.dyn.telefonica.de] has joined #code |
| 21:41 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 21:41 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 21:50 | <&jerith> | To quote myself from earlier: <&jeroud> "High-performance polyglot VM" -- I am skeptical. |
| 21:50 | <&jerith> | They've probably done the easy 80%. |
| 21:51 | <&jerith> | Now they need to do the hard 80% (which will likely mean trading off performance and compatibility) and the really annoy edge case 80%. |
| 21:52 | <&jerith> | *annoying |
| 23:09 | | Kindamoody is now known as Kindamoody[zZz] |
| 23:12 | <&ToxicFrog> | jerith: based on what they've published, "the easy 80%" is a JVM with better performance than Hotspot, a much nicer FFI, and a compilation mode that emits native binaries, which isn't revolutionary but isn't peanuts either. |
| 23:13 | <&jerith> | 80% of a JVM.~ |
| 23:20 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 23:27 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 23:30 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 23:30 | | mode/#code [+o Alek] by ChanServ |
| --- Log closed Thu Apr 19 00:00:38 2018 |