samcv | .ask TimToady should <control-000c> be uppercase or lowercase? <control-000c> or <control-000C> | 00:05 | |
yoleaux2 | samcv: I'll pass your message to TimToady. | ||
samcv | sweet almost done getting all unicode alias names programmatically working in moarvm | 00:11 | |
now just need to check on the cases i need to add since i'm gonna remove the unicode 1 names | |||
u: { .uniname.contains('(') } | |||
unicodable6 | samcv, U+000A LINE FEED (LF) [Cc] (control character) | ||
samcv, U+000C FORM FEED (FF) [Cc] (control character) | |||
samcv, gist.github.com/fd5640dd527c3b85c1...66764d9aab | |||
samcv | brokenchicken, not sure if you know about this misspelled unicode name | 02:24 | |
m: say 0xFE18.uniname | |||
camelia | rakudo-moar 8f3476: OUTPUT«PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET» | ||
samcv | BRAKCET < it can never be corrected in the official name because they're immutable, though there is an entry in the NameAliases | 02:25 | |
m: say 0x4E00.uniname | 02:26 | ||
camelia | rakudo-moar 8f3476: OUTPUT«<CJK Ideograph>» | ||
samcv | ok there's a ton of ideographs we don't construct names for… so many things to do | 02:27 | |
Geth | ast: c9c0390560 | usev6++ | S03-metaops/zip.t [JVM] Fix number of fudged tests for RT #130532 |
05:58 | |
lizmat | Files=1164, Tests=56527, 185 wallclock secs (11.00 usr 4.38 sys + 1107.87 cusr 114.74 csys = 1237.99 CPU) | 07:49 | |
samcv | hi lizmat o/ | ||
somebody said you may be a good person to be the Grant Manager for my WIP perl 6 grant | 07:50 | ||
draft is here gist.github.com/samcv/ca70c21c7306...220c986b47 some discussion on it in #perl6 | |||
[Tux] | drumrolllllllllll … | 08:09 | |
This is Rakudo version 2016.12-280-g8f3476d5d built on MoarVM version 2016.12-104-g64e2d938 | 08:11 | ||
csv-ip5xs 2.944 | |||
test 12.161 | |||
test-t 4.919 | |||
csv-parser 13.643 | |||
TADA! | |||
samcv | [Tux], how fast does the sit's graphs update | 08:12 | |
it says last updated 01-04-2016 | 08:13 | ||
but that can't be true | |||
since the charts are more up2date | |||
[Tux] | samcv, the page itself does not update: the last update stamp is when the page was updated itself (it is all static html) | 08:15 | |
the images it shows and the CSV data it links to get refreshed | |||
immediately | |||
samcv | k | 08:16 | |
[Tux], is there a way to graph it as % change? | 08:21 | ||
[Tux] | probably, but not by me | 08:24 | |
arnsholt | samcv: I plotted the ratio of test-t to csv-ip5xs yesterday | 08:25 | |
Summary is that it's improving nicely over the last year or so | |||
samcv: Also, definitely go for a grant proposal | 08:26 | ||
samcv | :) | ||
lizmat | samcv: looking at proposal now | 08:37 | |
re being a grant manager: I'm not sure I'm the best person for that | 08:42 | ||
samcv | kk that's fine. perlpilot_ just mentioned you | 08:43 | |
lizmat | re the shortcircuiting behaviour of && || and friends, and the fact you cannot override them (RT #130540) | 09:04 | |
I wonder whether we perhaps need a new kind of signature that would make this work: | 09:05 | ||
sub a(*@a) { dd @a.shift }; my $a = 0; a $a++,$a++; dd $a # sorta expected to see $a = 1 here | |||
m: sub a(*@a) { dd @a.shift }; my $a = 0; a $a++,$a++; dd $a | |||
camelia | rakudo-moar 8f3476: OUTPUT«0Int $a = 2» | ||
lizmat | aka, a lazy slurpy signature | ||
which would allow && || and friends to become full HLL citizens, rather then needing to be handled at codegen level and thus make them unoverridable | 09:06 | ||
samcv | lizmat, we have some test files that are specific to rakudo right? | ||
not p6 lang specific | |||
lizmat | samcv: yes, they live in the t dir in the rakudo repo | 09:07 | |
"make test" | |||
samcv | kk | 09:08 | |
and are they fudged too or no? can i do backend specific impl? | |||
lizmat | doesn't look like they're fudged | 09:09 | |
make test doesn't pass --fudge | 09:10 | ||
samcv | i mean i want to make backend specific tests | ||
for moarvm | 09:11 | ||
lizmat | hmmm... not sure how we can do that atm | 09:12 | |
samcv | oh well not like super critical but would be nice to add some tests for moarvm propcodes | 09:13 | |
lizmat | but aren't we going to expose that at some HLL level anyway? | 09:15 | |
and shouldn't we thus test it there, in roast ? | |||
samcv | uhm well checking that 'space' == 'White_Space' | ||
the propcodes are not specific to each impl | 09:16 | ||
and can change between moarvm revisions on changes to the unicode database | |||
lizmat | so it's more like an assertion ? | ||
samcv | m: use nqp; say getunipropcode('space') | 09:17 | |
camelia | rakudo-moar 8f3476: OUTPUT«5===SORRY!5=== Error while compiling <tmp>Undeclared routine: getunipropcode used at line 1» | ||
samcv | m: use nqp; say nqp::getunipropcode('space') | ||
camelia | rakudo-moar 8f3476: OUTPUT«===SORRY!===No registered operation handler for 'getunipropcode'» | ||
samcv | m: use nqp; say nqp::unipropcode('space') | ||
camelia | rakudo-moar 8f3476: OUTPUT«99» | ||
samcv | m: use nqp; say nqp::unipropcode('space'); say nqp::unipropcode('White_Space') | ||
camelia | rakudo-moar 8f3476: OUTPUT«9999» | ||
samcv | those should be equal. and also if the grants accepted i'll also add tests for 'SPACE' propcode == 'space' propcode and other things but that will come after i rewrite ucd2c.pl | 09:18 | |
assuming the grant is accepted | 09:19 | ||
will probably programmatically test all valid unicode identifiers as per the spec or whatever for a list of names | 09:20 | ||
i guess i could add in in nqp spectest? | 09:21 | ||
does that do fudging? | |||
lizmat | samcv: no idea | 09:22 | |
looking at the m-test target in the Makefile, I would say no | 09:23 | ||
afk for a few hours& | 09:31 | ||
brokenchicken | samcv: typo in proposal "This very important" | 11:07 | |
samcv | thanks brokenchicken. going to bed now. night o/ | 11:09 | |
brokenchicken | night | 11:10 | |
buggable: speed | 11:11 | ||
buggable | brokenchicken, ▆▇▆▅▆▅▄▄▅▅▃▂▃▃▄▃▄▆▃▄▅▃▅▄▄▃█▆▃▃▄▄▃▄▄▄▅▄▅▅▆▄▄▆▄▄▅▄▁▁ data for 2016-12-23–2017-01-12; range: 4.919s–5.958s | ||
brokenchicken | w00t | ||
grants require specifying nationality? | 11:36 | ||
Do they need all of them? | 11:37 | ||
with my luck, US will be at war with Russia by the time I apply :P but then, all my documents expired like a decade ago, so I'm probably not a national of Russia anymore? | 11:38 | ||
jnthn | As I understand it, it's something like: nationality is where you were born, citizernship is where you hold passport(s), residence is where you've got permission to live | 11:46 | |
Though it's a bit more involved than "where you were born" I guess | 11:47 | ||
brokenchicken | "Nationality is the legal relationship between a person and a state.": en.wikipedia.org/wiki/Nationality | 11:48 | |
hm... "In English and some other languages, the word nationality is sometimes used to refer to an ethnic group" | |||
jnthn | oh, hmm | 11:49 | |
Man, the complexity of it all | |||
"I'm just a human being dammit" :) | |||
brokenchicken | +1 :) | 11:50 | |
jnthn | But yeah, I suspect the reason they ask is because TPF is subject to US law and there are various sanctions in place. | ||
lunch & | 11:55 | ||
brokenchicken | I guess I'll follow samcv's example and submit a small proposal to TPF as well... | 11:59 | |
lizmat | :-) | 12:01 | |
jnthn | :-) | 12:16 | |
jnthn is 35 hours away from needing to renew his also | 12:17 | ||
Need to blog about recent stuffs also... | 12:18 | ||
Geth | kudo/nom: fab1a14f79 | (Elizabeth Mattijsen)++ | src/core/Array.pm Streamline Array.from-iterator - for some reason, a reify-until-lazy was always done - so I took a bit from the logic of reify-until-lazy in here - if the iterator fully reifies, then we don't bother setting up a todo with all of its complexities, but create a fully reified Array object with just a $!reified attribute and nothing else - otherwise it is business as usual, setting all of the todo and associated objects - makes Array.from-iterator(^10 .iterator) 30% faster |
12:53 | |
kudo/nom: 94acf2fa0b | (Elizabeth Mattijsen)++ | src/core/Array.pm Streamline Array::ArrayReificationTarget.new a bit It's probably not much, but if you're using arrays a lot, this may be noticeable. |
13:16 | ||
lizmat | afk& | 13:18 | |
Geth | kudo/js: 4 commits pushed by pmurias++
|
14:26 | |
kudo/js: b64da2964c | (Pawel Murias)++ | src/main.nqp [js] Add the --beautify command line flag. |
14:29 | ||
jnthn | Grr. The code-gen for `$x //= do { ... }` seems to fail to nest the closure on the RHS so it doesn't capturelex right. IO::Handle.open uses this construct. Result: concurrent app sometimes opens files with wrong mode. :( | 16:41 | |
TimToady | It's all my fault, even when it isn't. :) | 16:56 | |
yoleaux2 | 11 Jan 2017 08:39Z <lizmat> TimToady: one would expect this to be lazy, no? .say for "fileA".IO.lines >>~<< "fileB".IO.lines | ||
11 Jan 2017 08:40Z <lizmat> TimToady: or something like: ("fileA".IO.lines >>~<< "fileB".IO.lines).head(5) ??? | |||
00:05Z <samcv> TimToady: should <control-000c> be uppercase or lowercase? <control-000c> or <control-000C> | |||
TimToady | .tell lizmat I would NOT expect >>~<< to be lazy; that's what Z~ is for | 16:57 | |
yoleaux2 | TimToady: I'll pass your message to lizmat. | ||
TimToady | .tell samcv I lean towards uppercase hex for unicode, simply because U+1ABC is usually that way | 17:01 | |
yoleaux2 | TimToady: I'll pass your message to samcv. | ||
ggoebel | .ask pmurias I've been unsuccessful trying to follow your build instructions for rakudo-js. Getting hung up being unable to install the [email@hidden.address] dependency on node v7.4.0. Any tips? | 17:28 | |
yoleaux2 | ggoebel: I'll pass your message to pmurias. | ||
TimToady | .tell lizmat note in particular that .lines on a normal file can usefully be parallelized by seeking into the middle of a file and tossing the next partial line to sync up, so I don't think we should make hypers double-think their bias toward eager there just because .lines is typically used lazily | 18:09 | |
yoleaux2 | TimToady: I'll pass your message to lizmat. | ||
TimToady | .tell lizmat and we don't want to put artificial barriers in the way of parallelizing the map parts of map/reduce operations to the extent possible | 18:45 | |
yoleaux2 | TimToady: I'll pass your message to lizmat. | ||
TimToady | .tell lizmat as for »+« producing List or Seq, the desirable answer is none of the above, but rather HyperSeq, I suspect | 18:51 | |
yoleaux2 | TimToady: I'll pass your message to lizmat. | ||
brokenchicken | :o | ||
u: hyper space | 18:52 | ||
unicodable6 | brokenchicken, Found nothing! | ||
brokenchicken | aww :} | ||
TimToady | ain't even anything with "hyper" | 18:53 | |
jnthn | TimToady: Hmm, I'd had hypers down as replicating the incoming structure... | ||
(So that if you shoved shaped arrays in, you'd get shaped out) | |||
And similar with nesting | |||
TimToady | well, yeah, but that's somewhat independent of parallelizing | 18:54 | |
maybe we need Hyper[Array] and such | |||
jnthn | I'd figured that >>+<< and >>.foo would parallelize "on the inside", if you like | 18:55 | |
While .hyper/.race move you to a HyperSeq | |||
So you can chain operations like .map(...).grep(...).map(...) and it'll be smart enough to batch incoming items up and do all the work for those items on the same thread for better locality | 18:56 | ||
(That is, the pipeline is replicated over the threads, and each thread deals with a batch of data) | |||
In contrast to how ==> is meant to work, which is that it does producer/consumer and each stage is a thread. | |||
I grant all this is how I'd speculated about it being. :-) | 18:57 | ||
Not "how it must be" :) | |||
TimToady | I just think that, long-term, we're gonna want more of a two-way negotiation, and in that case propagating laziness through hypers is a bit problematic to "take back", especially when we already have a different notation for that | 19:00 | |
jnthn | I think we're agreeing here. In summary, "hyper/race are forms of eager". | 19:02 | |
TimToady | so I guess for now the ruling is »+« oughta produce a List, not a Seq | 19:04 | |
to allow the optimizer to insert pipeline negotiations between hyperops at some future point | 19:05 | ||
jnthn | *nod* | ||
TimToady | and hypers on known .is-lazy should probably fail outright and point the user toward X and Z instead | 19:11 | |
TimToady has also been pondering whether it's worthwhile to give all fates a unique id so we can distinguish subfates in a linear list, or whether it's worthwhile to take a more structural approach like STD did... | 19:27 | ||
if the former, any given dispatch would know to pay attention to the fates allocated in its own NFA's range, and pass smaller fates on to sub-dispatches | 19:29 | ||
so it would be balancing list scanning vs allocation of sublists, and I suspect with modern CPUs the list scanning would be faster | |||
especially if the hits are usually at the front of the list | 19:30 | ||
otoh, with a sufficiently smart NFA cache, one could imagine the result of scanning "sub" would only ever allocate its fates once for that result, in which case a structural approach wouldn't cost much | 19:34 | ||
⚖ | |||
in any case, giving fates unique ids would take some pressure off of copying states from one NFA to another, if we can come up with an NFA engine that can call into subrules and return somehow | 19:36 | ||
brokenchicken | u: ⚖ | ||
unicodable6 | brokenchicken, U+2696 SCALES [So] (⚖) | ||
TimToady | so there's potentially a sizeable win there on memory usage if we can reuse subrule NFAs without copying | 19:38 | |
so I'm thinking of moving in the unique id direction regardless of whether we do linear or structural | 19:39 | ||
might be some bootstrap issues with NFAs knowing what to subtract from their own fates though | |||
brokenchicken | .oO( National Fire Academy.... National Flute Association... National Fireworks Association... Noise-Figure Analyzer... ) |
||
What's NFA? | 19:40 | ||
TimToady | non-deterministic finite-state automaton | ||
brokenchicken | :o fancy | ||
TimToady | what we do LTM with | ||
lizmat | . | 19:44 | |
yoleaux2 | 16:57Z <TimToady> lizmat: I would NOT expect >>~<< to be lazy; that's what Z~ is for | ||
18:09Z <TimToady> lizmat: note in particular that .lines on a normal file can usefully be parallelized by seeking into the middle of a file and tossing the next partial line to sync up, so I don't think we should make hypers double-think their bias toward eager there just because .lines is typically used lazily | |||
18:45Z <TimToady> lizmat: and we don't want to put artificial barriers in the way of parallelizing the map parts of map/reduce operations to the extent possible | |||
18:51Z <TimToady> lizmat: as for »+« producing List or Seq, the desirable answer is none of the above, but rather HyperSeq, I suspect | |||
lizmat | TimToady: ok, clear :-) | ||
TimToady | see also subsequent discussion with jnthn | ||
lizmat | TimToady: yeah, read up on it, thanks! | 19:46 | |
TimToady: what about a lazy slurpy signature allowing infix:<&&> and friends to become HLL citizens ? | 19:47 | ||
TimToady | there are also two approaches to making NFAs call into existing subrules: 1) use pointers to those subrules, and keep all state transitions as pointers, or 2) keep all NFAs in a single array that we add new NFAs to | 19:48 | |
either of those has GC ramifications | |||
#1 ensures a lot of NFA walking, while #2 means it's hard not to leak memory if there are lots of throwaway NFAs from, say, EVAL | 19:51 | ||
also, we probably run into threading issues if two NFAs are trying to add themselves to the global state array at the same time | 19:54 | ||
otoh, serializing a single huge NFA array probably has optimization potential, especially if we know we can use smaller integers in spots | 19:56 | ||
lizmat: I dunno, control flow is hardwired into the compiler at a pretty fundamental level, and the compiler currently just considers && and || to be 'if' and 'unless' in disguise, and strips that disguise fairly early | 19:58 | ||
we'd probably end up doing a fair amount of pessimization to support that | |||
lizmat | well, this *is* about torturing the developers after all :-) | ||
TimToady | and hopefully this is more in the province of infix macros someday | 19:59 | |
lizmat | also, the compiler was made before GLR | ||
so maybe we just need to bring some of the GLR things lower in, or lift them up higher (it's all relative :-) | 20:00 | ||
TimToady | sounds like pessimization to me... | ||
lizmat | perhaps: but that is definitely not my goal :-) | 20:01 | |
TimToady | "Logic is something you can depend on--oh wait, maybe not..." | ||
lizmat | sounds logical to me :-) | 20:02 | |
TimToady | well, maybe not :) | ||
but it least rises to the level of a gut feeling | |||
*at least | |||
lizmat | ok, good enough for me :-) | 20:03 | |
jnthn | (signature for ||/&& style things) that's what macros are for | 20:55 | |
Oh, TimToady said that :) | 20:56 | ||
TimToady: fwiw, avoiding global mutable state in the design would be rather preferable ;) | |||
TimToady: Both for threading reasons and lifetime management reasons. | |||
(Yes, I can see you're already pondering those issues, just indicating the ones that scare me more :)) | 20:57 | ||
moritz | jnthn: any chance you could take at look at github.com/jnthn/p6-test-scheduler/issues/1 soonish? | 20:59 | |
jnthn | moritz: I don't think it can be addressed properly until we have non-blocking await | 21:00 | |
moritz: The issue is that another thread is waiting on a cond var | |||
samcv | morningish o/ | ||
yoleaux2 | 17:01Z <TimToady> samcv: I lean towards uppercase hex for unicode, simply because U+1ABC is usually that way | ||
moritz | jnthn: :( | ||
samcv | thanks TimToady | 21:01 | |
jnthn | moritz: And we release it, but can't really have any control over the execution that happens. | ||
moritz: otoh, getting that in place is nearing the top of my todo list | |||
moritz | jnthn: \o/ | ||
jnthn | Part of the MoarVM ->work cleanup of late that got us the nice CORE.setting built time improvements was also aimed at preparing the ground for that. | 21:02 | |
samcv | moritz, grant manager would be fine by me. any comments on my draft of the proposal? | ||
masak | I missed the backlog about || and && stuff, but "that's what macros are for" sounds about right | ||
if it's thunkish (like infix:<xx>), then a macro would be the right hammer to implement that | |||
jnthn | (Call frames should now be transplantable across threads in continuations, safely) | ||
moritz | samcv: the first deliverable sounded a bit vague, IMHO | 21:03 | |
samcv | i will expand on that some more then | ||
jnthn | samcv: Hm, think I missed the link to the proposal...I can take a look if you'd like | ||
moritz | samcv: can you give me the link to the gist once more please? | ||
samcv | yep | ||
gist.github.com/samcv/ca70c21c7306...220c986b47 | |||
jnthn | samcv: Looks good to me | 21:06 | |
samcv: Except missing synopsis :) | |||
samcv | yeah hah | ||
TimToady | jnthn: another consideration is whether we ever want to make the NFA pre-emptible by something that could GC | ||
jnthn | Looks like worthwhile work to me | ||
TimToady: That all depends on how long we think we might spend inside of the runner. | 21:07 | ||
TimToady | well, if we're smart enough, it shouldn't be needed for .*? 'foo' | ||
but foo* could find an awful lot of o in some applications | 21:08 | ||
jnthn | TimToady: But in MoarVM at least that's largely just a case of sticking calls at safe points/back branches to check if we got interrupted | ||
*nod* | |||
TimToady | just sayin' the pointer approach has to allow for pointers to change, if so | ||
jnthn | Yeah, that's true. | ||
The GC needs to know where all pointers are so they can be updated. If they're already stuck into a structure it knows about, then that suffices. | 21:09 | ||
So that "just" leaves the C stack | |||
(Which is that the MVMROOT macro is for) | |||
TimToady | I presume that works well with how the optimizer likes to put some things into registers, or we wouldn't run at all :) | 21:11 | |
moritz | samcv: just a quick comment on the update frequency, you should measure those in weeks, not days | 21:12 | |
samcv: unless you totally want to do that as a full-time job :-) | |||
samcv | i'm not working so I could | ||
it really depends how many hours I want to commit to | 21:13 | ||
(per month) | |||
TimToady | jnthn: on the gripping hand, I don't think the typical program is going to have much contention for the NFA table, though it's possible to imagine a scenario where it could | 21:15 | |
and if we did run into that scenario, it would be easier to degrade an array-based solution back to what we have now than a pointer-based solution, I suspect, especially since we'd really only wanna do subrule re-use like that in derived grammars, not fresh ones | 21:17 | ||
so the scenario would have to involve multiple threads trying to derive off the same grammar in different directions | 21:18 | ||
TimToady doesn't want to think about MI right now... :( | 21:19 | ||
though I suppose we could just say, you use MI, you get back to copying subrules | |||
ggoebel | .ask pmurias looks like bigint has problems with js v8... was able to get past that by using node v0.10.48 | 21:20 | |
yoleaux2 | ggoebel: I'll pass your message to pmurias. | ||
TimToady | another consideration is which approach might be more amenable to eventual DFA optimization... | ||
though, tbh, I suspect the current longest-literal semantics are going to cause more interference here than will how we represent state edges | 21:23 | ||
jnthn | TimToady: Multiple threds *reading* the same table is unproblematic. It's when we get into mutating things that we get into trouble. | ||
TimToady | right, my "scenario" above was talking about writing | 21:24 | |
jnthn | Persistent data structures also have nice properties here | ||
(The trie we use for NFG synthetic resolution is such an example) | |||
Where we never truly mutate stuff, just make new versions and that share what's possible of the previous version. | 21:25 | ||
TimToady | that's more or less what we want to do with derived grammars | ||
we ain't, currently | |||
well, at least, not at the subrule level | 21:26 | ||
jnthn | yeah, at the moment deriveds share nowt. | 21:27 | |
Which gets costly fast. | |||
TimToady | we do share to the extent that a method call bypasses a non-existing method in the derived class | ||
(I think) | |||
jnthn | True | 21:28 | |
TimToady | so if you extend in the term: namespace, you shouldn't necessarily have to recompute the infix: namespace | ||
jnthn | But I think the NFAs are cached in the meta-object | ||
And at a per-class level | |||
If you never *use* infix: then you'd never recompute it | |||
TimToady | okay, well, that's a little sucky then | 21:29 | |
jnthn | "Simplest thing that could possibly work and not leak" ;) | ||
But yes, there's ample room for improvement. :) | |||
TimToady | you sure it's not cached on the proto method? | ||
jnthn | Yes, looks very MOP-y: github.com/perl6/nqp/blob/master/s...r.nqp#L333 | 21:30 | |
I mean, the method name is the cache key | |||
But it's a hsah inside of the meta-object | |||
Gotta go for a bit; bbl | 21:31 | ||
pmurias | . | 21:46 | |
yoleaux2 | 17:28Z <ggoebel> pmurias: I've been unsuccessful trying to follow your build instructions for rakudo-js. Getting hung up being unable to install the [email@hidden.address] dependency on node v7.4.0. Any tips? | ||
21:20Z <ggoebel> pmurias: looks like bigint has problems with js v8... was able to get past that by using node v0.10.48 | |||
pmurias | .ask ggoebel bigint is not used by nqp-js | 21:47 | |
yoleaux2 | pmurias: I'll pass your message to ggoebel. | ||
pmurias | .ask why is it being installed? sorry if you found outdated build instruction somewhere :/ | 21:49 | |
yoleaux2 | pmurias: I'll pass your message to why. | ||
Geth | kudo/nom: c301b042aa | (Elizabeth Mattijsen)++ | 16 files Introducing Rakudo::Iterator A dummy class for keeping (and documenting) Rakudo internal iterators. These used to live in Rakudo::Internals, but it is getting a bit crowdy in there. By creating a separate class, we can also rename the iterators to something shorter and more easily greppable. So far these have been migrated: Internals::BlobbyIterator Iterator::Blobby Internals::MappyIterator Iterator::Mappy ... (2 more lines) |
21:55 | |
ggoebel | pmurias: brown bag moment... I went down the rakudo-js rabbit hole... Realized my mistake and am now working against perl6/nqp | 21:57 | |
yoleaux2 | 21:47Z <pmurias> ggoebel: bigint is not used by nqp-js | ||
ggoebel | make js-test isn't working because it can't find nqp-runtime (no node-module directory) | 21:58 | |
if you do a make js-bootstrap, cd into nqp-js-on-js, and execute node nqp-bootstrapped.js -s "say('hello')" if fails because it can't find nqp-js-compiled-stuff/ModuleLoader | 22:01 | ||
pmurias | I'll check out a fresh repo and see why it's not installed... | 22:02 | |
ggoebel: the old rakudo-js repo on github? | 22:03 | ||
ggoebel | pmurias: yes that old repo... | 22:06 | |
pmurias | sorry, should have marked it as obsolete :( | 22:08 | |
I have nqp-runtime linked with 'npm link' into the nqp-js-repo/node_modules | 22:09 | ||
ggoebel | pmurias: bbiab I've got to go grab food to feed the kids | 22:12 | |
pmurias | ok | ||
the whole way nqp-js/rakudo-js is build need to be burned down and replaced :/ | 22:13 | ||
ggoebel | pmurias: well if I can figure out how to get to "hello world"... I'll try to help | ||
samcv | i'm trying to override ./nqp/src/HLL/Actions.nqp to deprecate some unicode 1 names but it doesn't seem to be working | 22:17 | |
need to override the charname method | |||
pmurias | ggoebel: mkdir node_modules; npm install src/vm/js/nqp-runtime | 22:18 | |
samcv | need to override github.com/perl6/nqp/blob/master/s...s.nqp#L205 in rakudo since there's no warn functionality I was told in NQP | 22:19 | |
that can be turned off with quietly | |||
tried putting new methods in class Perl6::Actions is HLL::Actions does STDAction in src/Perl6/Actions.nqp but that didn't seem to affect anything. do I need to override some other place too? | 22:20 | ||
pmurias | ggoebel: make js-test should work after that, with the exception of one module that need tap to be installed | 22:22 | |
Geth | kudo/nom: 077a7523e5 | (Elizabeth Mattijsen)++ | 5 files Migrate Internals::ShapeLeafIterator to Iterator::ShapeLeaf Also document Iterator::ShapeLeaf a bit more |
22:26 | |
p: 207831cec3 | (Pawel Murias)++ | src/vm/js/nqp-runtime/package.json [js] Add missing dependency to package.json. |
|||
p: 1e27ff5450 | (Pawel Murias)++ | README.pod [js] Update build instruction. |
|||
samcv | pmurias, so the js backend is basically a node backend yes? | 22:27 | |
and it basically plans on being dependent on node for its runtime support | |||
Geth | p: babd0dcd5b | (Pawel Murias)++ | README.pod [js] Update README. |
22:28 | |
pmurias | samcv: there are tools (like webpack) that pack node.js style code and allow it to be used in the browser | 22:29 | |
samcv: is there anything besides node.js that you want to run js code on? | 22:30 | ||
samcv: I'm not depending on node.js itself for stuff other than IO | 22:38 | ||
samcv | gotcha | ||
pmurias | I'm not node.js expert it's just a convinient way of running js code from the CLI | 22:42 | |
ggoebel: sorry for wasting your time with the silly build system, I have to go to sleep but I'll think how to replace it with something less despicable tommorow | 22:46 | ||
Geth | kudo/nom: f10b09e274 | (Elizabeth Mattijsen)++ | 5 files Migrate Internals::ShapeBranchIterator to Iterator::ShapeBranch Also document Iterator::ShapeBranch a bit more |
22:50 | |
lizmat | good night, #perl6-dev! | 22:51 | |
brokenchicken | night | ||
jnthn | samcv: It needs to go in Perl6::RegexActions or so, which inherits from P6Regex::Actions, not the Perl6::Actions which is for the main language | 22:57 | |
samcv | ah ok thanks | ||
jnthn | Happy hacking. Sleep time for me. :) o/ | 23:01 | |
TimToady | jnthn: upon reflection, the caching has to be per-class, since we can't guarantee subrules are redefined | ||
jnthn | TimToady: Hmm | ||
But surely within that we can find a bit more sharing? :) | 23:02 | ||
TimToady | surely! sleep well | ||
jnthn | Some kind of tail sharing would go well with GC and thread safety... | ||
Thanks; 'night |