Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Elia Schito
@elia
@Mogztter updated thanks!
Guillaume Grossetie
@Mogztter
:+1:
Ghost
@ghost~59874280d73408ce4f704e9c
:+1:
Ghost
@ghost~59874280d73408ce4f704e9c
opal-zeitwerk 0.1.0 -> major step forward, now works just like the original one also with explicit namespaces that use TracePoint internally.
(requires es6_modules_1_1 branch with TracePoint support etc.)

@fkchang guess in Flutter/dart you still have to type:

import 'package:flutter_web_ui/ui.dart' as ui;
import 'package:flutterwebdemo/main.dart' as app;

So ugly. I very much prefer ruby comfort, basically omitting all
require 'whatever'
(as default in isomorfeus for example)
;)

Forrest Chang
@fkchang
@janbiedermann I'm not personally a Dart fan, a co worker was (is?) - I was waiting for it get some traction before I decided to look into it
so flutter looks like it could be the thing to bring traction to Dart
otherwise, not a big fan of "yet another language not very different that existing languages" type of languages.
Ghost
@ghost~59874280d73408ce4f704e9c
As i am working on getting autoload working according to ruby specs, i hit a problem where ruby specs clash with opal reality. ruby/core/module/fixtures/classes.rb contains a dynamic autoload, which we can't fulfil, because we need the filename at compile time. With autoload working, that causes trouble for many specs that require that file. My current "solution" is to copy the specs into opal/core/module and let them there require fixed files, copied from ruby spec too, where i replaced the dynamic autoload/require with the known filename.
Is there a better way? Maybe a way where i can somehow "inject" the fixed classes.rb into ruby specs?
Guillaume Grossetie
@Mogztter
The Opal compiler does not compile the target of a load directive. Is that intended?
Ghost
@ghost~59874280d73408ce4f704e9c
There is no "special" thing in the compiler for load, just the runtime method call.
Not sure if intended, but if provided, whats the difference to require? Its always executed then.
You could emulate that with a require in place, followed by a load:
load 'bla' unless require 'bla'
Guillaume Grossetie
@Mogztter
I want to compile an existing Ruby library that uses load (instead of require): https://github.com/rouge-ruby/rouge/blob/39ec4a4d260491944aa9560bf3110a5336a81481/lib/rouge.rb#L39
the issue is that the code won't be generated so even if Opal generates the runtime method call it won't work (because the module wasn't generated)
Ghost
@ghost~59874280d73408ce4f704e9c
Right. And the line you linked to wont work anyway, because its a dynamic load, that is resolved at runtime. The compiler has no way of knowing at compile time which file is meant.
Maybe the easiest way is to arrange the files in way that you can do a require_tree and then load on demand.
(Or you try opal/opal#2056, you can do require_tree 'tada', :autoload, which includes the files in the bundle but does not execute the actual require, so then the load can be resolved later at runtime, just like you would require)
Ghost
@ghost~59874280d73408ce4f704e9c
Orignally meant for autoload, but well, seems to be useful for your case too.
As the line suggests that all those files are contained in a directory, sticking that require_tree even outside of the rouge them within your code should suffice.
Guillaume Grossetie
@Mogztter
Oh nice, I will give it a try and propose a patch in Rouge, thanks :+1:
Ghost
@ghost~59874280d73408ce4f704e9c
Guillaume Grossetie
@Mogztter
as far as I know they are using load to provide "live reload" in development (when you make changes to the codebase)
Guillaume Grossetie
@Mogztter
load means the library is reloadable in testing, which is really important for the lexer development flow. is it causing problems?
I'm not a Ruby expert, does it makes sense to use load in "production" code to make the library reloadable in testing?
Is there a strong argument to not do that?
I think they should use require but I don't want to sound like it's a personal preference
Elia Schito
@elia
We should make load behave properly
The behavior for the two methods is different and they have a good case for using load
Guillaume Grossetie
@Mogztter
Alright :+1:
Did you see my comment about codeclimate on opal/opal#2061 I don't understand the report :pensive:
Elia Schito
@elia
@Mogztter thanks for the patience, I marked them as invalid, the report was just a false positive
@Mogztter can you also please update the commit message to just describe the change (without the resolve)?
Guillaume Grossetie
@Mogztter
@elia cool thanks, and done :)
I was wondering if the "2 spaces before ### titles" helps with conflicts in the changelog?
I've added a changelog on Asciidoctor.js but dealing with conflicts on almost every single pull request is really annoying
Elia Schito
@elia
it's possible, but tbh, was just my pet peeve about reading markdown without rendering and getting a feel of the hierarchy

I've added a changelog on Asciidoctor.js but dealing with conflicts on almost every single pull request is really annoying

completely agree, in fact lately I'm adding to the UNRELEASED after each PR merge, I do that from the web, it ends up in more commits but except from that works fine

Guillaume Grossetie
@Mogztter
I see, thanks for your input
Our initial, boring solution to the problem was to begin adding empty placeholder entries at the beginning of each monthly release cycle. The changelog for the upcoming unreleased version might look like this:
:laughing:
that's actually pretty cool, and when there's no slot available then it's time to release to avoid conflicts
Elia Schito
@elia
yeah, already tried, and bumped in the same problem… additionally doing the changelog entry after the merge relieves the contributors from yet another chore
Guillaume Grossetie
@Mogztter
I think I will do the same
the yaml solution by GitLab is a bit too much
Elia Schito
@elia
@Mogztter agree, anyway if you find any trick to improve this process let me know please, it's still a pain in the neck
Guillaume Grossetie
@Mogztter
Pretty cool
Guillaume Grossetie
@Mogztter
@elia I was about to suggest merge=union but you are already using it. Did you notice a big improvement?
Elia Schito
@elia
@Mogztter unfortunately it's not supported within GitHub so it's pretty pointless unless you always do the merging locally (sorry for the late response)