github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 3 May 2018.
01:58 ilbot3 joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
05:18 unicodable6 joined, statisfiable6 joined, greppable6 joined, nativecallable6 joined, quotable6 joined, committable6 joined, undersightable6 joined 05:58 domidumont joined 06:22 domidumont joined 06:37 AlexDaniel joined 07:15 robertle joined
AlexDaniel squashable6: next 07:27
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in ≈2 hours (2018-05-05 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
07:57 domidumont joined 08:11 domidumont joined 09:22 brrt joined
brrt . 09:25
good *
lizmat brrt o/ 09:28
brrt ohai 09:32
did you get a chance to test jit-moar-ops
lizmat no :-(
breakfast&
brrt no problem 09:34
lizmat: I saw also, in the whole thread, this: news.ycombinator.com/item?id=7807083 09:39
09:40 Ulti joined
brrt and it was funny because building a jit was apparently magical thinking 09:49
samcv lol at the "python 3 is killing python" though 09:59
09:59 robertle joined
Ulti has been programming in Python 3.6 for the last year 10:00
brrt i recently found out i don't know python as well as i thought 10:02
Ulti any moans about the 2.x 3.x thing are from a position of ignorance I tried 3.x about 5 years ago and it was a very different story to now
its totally fine now
brrt what surprised you? 10:03
brrt well, print being a statement in python2 10:04
that one keeps on giving
11:26 brrt joined 11:57 AlexDaniel joined
robertle "MoarVM panic: Internal error: invalid thread ID 1270578208 in GC work pass" is this a known problem? 12:59
lizmat I've seen it in the past, but not recently 13:03
robertle is there anything I can do to shine some light on it? 13:08
lizmat gist the code that produces the error and the versions you are using 13:09
jnthn Unfortunately, it's meaning i "there's memory corruption"
*is
robertle I am having trouble getting it into a less intermittent or smaller state, when I change it too much the problem disappears. but the version is This is Rakudo version 2018.04.1 built on MoarVM version 2018.04.1, and the code is github.com/robertlemmen/perl6-cache-async at g1f4dafd 13:13
i get it by running ./bench.pl6, about every otehr time 13:14
also managed to get a segfault! 13:16
jnthn Yeah, the error you got basically means "we know we're going to segfault if we continue" :) 13:17
robertle as well as a "Cannot look up attributes in a Perl6::Metamodel::ClassHOW type object", but that could well be a logic error in my code. although it's weird that the entries in the stack trace are all method definitions, not actual code lines that do something. of course there is some code related to the method entry, but usually I get these from stuff I wrote... 13:18
brrt it certainly seems like memory corroption of some kind 13:21
13:44 AlexDaniel joined 13:48 zakharyas joined 13:59 brrt joined
nine Ulti: there is still to this day no way to get our ~ 1.5 million lines of Python 2 code to run on Python 3. I'd love to be proven ignorant on that. 14:01
Ulti no way, or no way without effort 14:11
I meant more that python 3 itself is entirely viable on its own now
I dont really understand the fad idea of why you would upgrade if you have a perfect servicable python 2 code base
nine Well since there's no way we could affort to port it manually, I'd say no way.
Because support for Python 2 will run out? 14:12
Ulti and what form does that support take that has an impact on your company?
nine In the long term it will become more and more difficult to even install it
Ulti by that time how relevant will your 1.5 million lines of code be, I mean banks sort of made this mistake with cobol I guess 14:13
nine It was 1.5 million years ago when I counted. It's probably a lot more now and growing. 14:14
Ulti nine: is new stuff written in the 2/3 style?
like it is possible to move gradually, I have no idea if its worth it to anyone 14:15
nine The thing is, it's not one large code base. It's Python expressions embedded in HTML templates (Zope's DTML) of 1500 customer websites. 14:18
brrt nine: i thought there was a python 2to3 converter? 14:21
Ulti the one thing I will say is I dont think python 3 offers enough for the fuss its causing 14:23
which is kind of interesting Perl 6 its too different for people to want to "upgrade" and Python 3 is too similar, makes you wonder if a sweet spot exists at all 14:24
brrt oh, that's easy. it is 'management mandates we do $x' 14:33
geekosaur that's just the workaround. underlying both is "I don''t like change" 14:50
and finding any excuse to avoid it
16:34 brrt joined 16:38 Ven`` joined 16:46 domidumont joined
samcv so, implementing index_by_codepoint is going to be more annoying than i thought. i'm still not sure how i want to do it 16:58
what i'd like is that we have a dual based indexing. where it'd return the grapheme number and the codepoint number. so like if it's the 30th grapheme and the 2nd codepoint in that grapheme, it'd return an array [29,1] 16:59
17:14 domidumont joined
jnthn samcv: I don't think we should implement codepoint operations on grapheme strings, but rather have codepoint strings 18:20
samcv: Probably what lies behind Uni should not be a VMArray (which was expedient at the time), but some kind of codepoint-level "string" 18:21
There's just a ton of design questions around it all
And what operations should be Str-coercing and what operations should be polymorphic
I don't think Str as a type should be mixing the levels, though. 18:22
timotimo will Uni be the type for that? 18:26
dogbert17 here's a gist of the SEGV reported by robertle earlier today, gist.github.com/dogbert17/f3cd8dd9...b40dffd460 18:28
jnthn Yes
jnthn wonders if he should try and write up what thoughts he has on Uni, as well as what design problems will need solving 18:29
samcv jnthn: yeah. i was thinking about that. which is why i started writing some code and then decided it was too early and i should think it out further :) 18:50
but. we should be able to do codepoint operations on a NFG string as well. but i agree we need operations that are by codepoint
since atm we just have NFG and NFC type things (plus utf8-c8)
jnthn Well, the overall design is that Str is grapheme level, Uni is codepoint level, and Buf is byte level 18:54
Well, also Str/Uni/Blob are immutable
Buf being a mutable Blob
Though none of these are Iterable 18:55
They're all items
But yeah, I figure that if one does something like Str.split(Uni) then that'd be a codepoint split on a Str 18:56
But I don't fancy a combinatoric explosion of these
Also an open question what Uni.substr(...) means
Under the principle that operations have consistent semantics across types 18:57
[Coke] /win 2
buggable [Coke], Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 6 days, 5 hours, 2 minutes, and 17 seconds
jnthn So is it conceptually Uni.Str.substr(...) (though with a potentially more efficient implementation to avoid the throwaway coercion) 18:58
That'd imply we want a subuni :)
Which'd go well with subbuf
My overall point here being I think we'll need to go through each of the operations one can do on a Str and decide what they mean, if anything, on a Uni 18:59
As well as defining stuff like Uni ~ Str, Str ~ Uni, etc.
Even before all of that, though, we'll need to deal with Uni I/O, and probably make a call on whether we're going to keep Uni as a VMArray or instead have it more like an MVMString 19:00
Which'll mean answering things like whether we want to have open("foo", :uni), open("foo", :nfc) etc. 19:01
And if so, does .get and .lines give you Uni and an iterator of Uni 19:02
So yeah, it's...big. :)
And this is before we even talk about the grammar engine. :)
19:20 FROGGS joined 19:22 brrt joined 19:31 robertle joined 20:20 Kaiepi joined
Geth MoarVM/jit-moar-ops: 9 commits pushed by (Bart Wiegmans)++ 20:40
20:52 Kaypie joined 21:22 MasterDuke joined 22:21 Ven`` joined
timotimo what the heck, appveyor wants me to choose which account to log in with; "timo" or "samcv" 23:21

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!