Archived messages from: gitter.im/red/red.js from year: 2021

GaryMiller
22:37Merry Christmas and Happy New Year! Any Red,js predictions/resolutions for 2021?

ALANVF
21:12@GaryMiller I'm hoping to finish the transition from TS to Haxe for Red.js this year (i.e getting back to where I was at in the original version)

GaryMiller
05:04Will be great to see. Realize you are aiming at a moving target! But its great to see that you're sticking with it!

ALANVF
20:33so whenever I get to implementing Parse, I had the idea of maybe compiling Parse rules to WebAssembly or something similar
20:33is Parse currently compiled, or is it still interpreted?
greggirwin
20:55Parse is written in R/S and is compiled.

ALANVF
01:39ah oh, thanks :thumbsup:
giesse
15:07is the question, are rules compiled then executed? if so, they are not, parse is an interpreter. compilation would break some usage.
15:08what @greggirwin means is that the interpreter is written in Red/System
15:09topaz-parse uses a compiler if that's useful to look at.
15:13eg. this: https://github.com/giesse/red-topaz-parse/blob/master/parse-parse.red
gets compiled to this: https://gist.github.com/giesse/f18230b8f097a2fb43a46684638737aa
greggirwin
17:21Excellent point @giesse. I should have thought a little more before posting.
ALANVF
20:05@giesse oh ok, that's still helpful though

ALANVF
22:14update: Haxe 4.2 has come out so I'm not transitioning to that

ALANVF
03:52OOPS I meant to say "now" not "not" LMAO
GiuseppeChillemi
08:25I have thought, is HAXE so incompatible that @ALANVF will remain to a lower version?
08:25:-))))))

ALANVF
18:14FINALLY GOT IT WORKING WITH HAXE 4.2 OMG
18:14that took way too long
toomasv
18:24:+1: Congratulations!
ALANVF
18:25thank you!
18:25(this is what I've been doing for the past several weeks btw lol)
18:25hopefully we can now have regular updates to red.js again
greggirwin
18:37Updates to our tools, when things change, is one of the most painful things to deal with. Everything's working and then...months later...everything's working again.
18:37Glad you got through it.
ALANVF
18:38yeah it wasn't the most pleasant thing to deal with, but it should make a lot of things much easier to work with now
greggirwin
19:42What were the biggest pain points? We try not to break things, but know what's hardest for users from a real world case like this is something we can learn from.

GiuseppeChillemi
15:02Nice question, I would like to see which difficulties you have encountered.
ALANVF
16:09@greggirwin A decent amount of it was just trying to work around Haxe's weird quirks, but a lot of it was mainly caused by not wanting to revisit (bad) old code
16:10Red thankfully doesn't have as many issues here as Haxe does, but I'm sure that there's still some old code that should probably be revisited at some point in Red's codebase (especially in R/S)

GaryMiller
23:54:+1: Congratulations! Keep up the good work! Hopefully future Haxe releases will be more backward compatible.

ALANVF

GaryMiller
20:38Just saw this and wondered if it would be synergistic with red.js under Haxe with the graphics, UI and compression libraries... https://hashlink.haxe.org/

ALANVF
02:45@GaryMiller as cool as it seems, I'd say probably not. I currently have a lot of code that's optimized/written for Haxe's JS backend, so that wouldn't easily transition over to Hashlink very well without using a custom fork (which would not be convenient for others). I am also using Hashlink for another project of mine (my programming language [Star](https://github.com/ALANVF/star)), and it seems to be a lot more annoying/boilerplate-y than JS, at least in Red.js' case

ALANVF
16:37update: dealing with end-of-year stuff for school rn. once that's over with, I'll be able to work on red.js more regularly
greggirwin
16:48Thanks for the update!

GaryMiller
04:10Looking forward to all the great progress!

ALANVF
00:48yay I'm done being dead for now
00:48[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/luqi/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/luqi/image.png)

GaryMiller
21:06Does that mean schools out?
greggirwin
21:13> yay I'm done being dead for now

I was going to ask if this was a zombie thing.
ALANVF
23:06@GaryMiller yeah I'm done with high school now
23:07@greggirwin does being a screen zombie count?
greggirwin
23:10I'm a fan of Fuzzy Logic, so yes.
ALANVF

ALANVF
01:59btw as an update (yes, another 3 weeks later), I'm optimizing some of the red.js internals because function!s are kinda slow rn
02:03this is mainly because haxe does not optimize Option values, which are basically type-safe nullable types because they're an enum (aka tagged union)
GaryMiller
19:59Haxe probably relies on the optimizers in the target compiler. Wouldn't the C compiler optimize them after the Haxe transpiles it? Or are the code changes to extensive for GCC optimizer?
ALANVF
21:29@GaryMiller well I'm targeting JS (cuz ya know, red.js) so C wouldn't help much anyways as haxe directly compiles to JS
21:30the other issue is that Option is just a regular type, not a magical compiler built-in, so it can't optimize it like regular nullable types (aka Null)
21:33unless I figure out how to use haxe's outdated JS generator (used for custom codegen rules and stuff), I'm probably gonna have to manually go through and replace some uses of Option with Null (because Null is not boxed on JS, as anything can be null)

GaryMiller
14:10Just thought that since emscripten converts from C to Javascript with very little speed penalty that there might be an advantage in leveraging the code optimization that C does first.

But if as you say Option could not be optimized any by the C compiler then there would be not advantage to generating C first and then going to JavaScript.

Having to alter JavaScript code after it has been generated Haxe each each time would get very tedious though unless you somehow automated the code changes in the make process correct?

ALANVF
20:31@GaryMiller well the thing is that the JS codegen thing that Haxe provides is part of the compiler api, so it directly changes how Haxe generates JS code at compile-time
20:32the main issue with it is that it's pretty old/outdated compared to what the compiler itself does
20:35here's the interface if you're curious: https://api.haxe.org/haxe/macro/JSGenApi.html

ALANVF
22:35yay removed a bunch of boilerplate with some fancy macros and stuff
22:36now to figure out why dead code elimination is broken

greggirwin
00:15Thanks for the update. Dead code elimination from your work, or Haxe back end?
ALANVF
00:16I guess for the backend? dead code elimination is basically a haxe feature where it optimizes the output code (in this case, JS) to get rid of stuff like unused types, functions, and variables
00:18unfortunately, it was ignoring a lot of types I had defined for natives, and the only solution was to disable DCE for the natives (which means they weren't optimized, not fun)
00:18I think I've got a fix for it now, but it's breaking something else so I gotta fix that too lol
00:20(and to no surprise, it was another DCE issue)
00:21in general DCE is supposed to be really helpful, but sometimes it can be counterproductive when using macros and stuff
greggirwin
00:38Optimizations are always a double-edged sword.
ALANVF

GaryMiller
00:43Have you chatted with any of the HAXE JS authors? They might have something on their RoadMap that would take of that allowing you to concentrate on the RED port. By removing their boilerplate you may make it more difficult to upgrade to future versions of HAXE/JS.

ALANVF
22:58yay some progress
22:58[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/ybtd/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/ybtd/image.png)
22:58also rewriting some datatypes to be more efficient and reflect their red/system impl
greggirwin
23:42Nice. Thanks for the update.
ALANVF

GaryMiller
02:37Exciting progress!
GiuseppeChillemi
07:42Good!
ALANVF

ALANVF
23:40yay new stuff
23:40bind/in coming soon
23:44I'm also gonna try putting up a runnable version of the new Red.js like the old version on replit sometime soon

greggirwin
03:50:+1:
GaryMiller
06:00Great news! Are you liking working with the new version a lot better than the old version?
ALANVF
16:28@GaryMiller it's been better in a lot of ways, although I haven't been too happy with how restrictive/incomplete haxe's type system is
16:29essentially, I've traded boilerplate for different boilerplate
16:31there's also the issue of haxe's codegen, which is frequently dumb and adds overhead when it's completely unnecessary
16:35(can probably meddle with the codegen later, but eh)

ALANVF
01:15yeeeeeeeee more natives added (bind, in, switch, and case) and fixed tons of bugs
rebolek
05:24:clap:
greggirwin
05:32Sounds like you're making great progress.

ALANVF
20:44been a few months, but I'm slowly getting more time to work on stuff
20:45I think I've also figured out how to make functions nested in objects work correctly
greggirwin
20:53:+1:
ALANVF
20:54in my old impl, I passed around the current context everywhere (which is how I made it work there), but that obviously caused some other issues
20:55apparently the object's context is bound to functions during creation only, although I'm still not 100% sure how self is bound but also inaccessible from the outside
20:58will continue investigating, but expect more stuff coming soon
23:25yay that works ig
23:25[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/ftKz/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/ftKz/image.png)
23:26no typechecking yet, but it works for now

greggirwin
16:13Cool. :+1:

gchiu
18:07What's the end game here for a GUI? Is it to implement VID in JS?
pekr
18:23I am not sure if it would not be wiser to map to something like Flutter. Btw, Graha - what is the state of Ren-C and WASM? Can it do R3 GUI?
cloutiy
20:17`textfield "First Name:" [ required autocomplete .class1 .class2 .class3]
20:19button "Submit" [ post items/new ]

ALANVF
02:54@gchiu either that, or a dialect similar to VID that's better for building/manipulating the DOM
02:56I can imagine that there would be a handful of dialects that would be used to expose much of JS' functionality in a nice and clean way, like using the DOM, async/await stuff, events, canvas, and maybe a R/S-like dialect for mapping to raw JS
gchiu
14:51@pekr i use renc regularly in browser for most of my work, but there's no current plan for a gui
cloutiy
19:18Would be interesting to see how to take advantage of an object's on-change function combined with websockets to deliver realtime changes between data and ui.
GiuseppeChillemi
19:23@gchiu How do you use RENC in browser? Have you some examples script somewhere?

gchiu
03:13@GiuseppeChillemi try this. At http://hostilefork.com/media/shared/replpad-js/ once the renc has loaded into the browser, and you see the replpad prompt, type do
03:14once that loads, type latest-of , or, simply latest-of 0.3.40
03:14the first detects the browser OS, and gives you a link to the latest builds for that os. in the second case I specify I want the build for windows 64
03:16I've got scripts that print out my timesheets and invoices which work by calculating various things and then populate docx with these values
03:17So, even though I'm working in a hospital where I can't install anything, I can still use rebol in any browser
03:18I've got another script that calculates which energy provider to use based on my current latest bill
03:28It's cool that we can use rebol in the browser to tell us where the latest build from CI is .. means we don't need to maintain a static web page
Oldes
10:41Sorry, but that is not Rebol anymore. At least for me.
10:59And btw.. latest-of is a pure name. I don't know why would anybody want to download ren-c for different os than the one currently using. And be forced to remember the cryptic system tuples. Does anybody remember the number for the Amiga version?
11:00Never mind.. wrong chanbel for such comments.

gchiu
04:43My chess demo is working again. http://hostilefork.com/media/shared/replpad-js/ and type do
04:44to play the demo game, type chiu-vs-jensen