Parrot 4.3.0 "In Which..." | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 25 April 2012.
whiteknight something has to be broked with that smoker 00:00
kid51 tt.taptinder.org/buildstatus/parrot/master
Or else, something is broken on Win32 build 00:01
cotto ~~
kid51 After dinner I'll have to file a bug ticket. 'make headerizer' apparently fails to update the HEADERIZER section of files when the change in a .c source code file is to *remove* a function that was previously headerized. 00:02
whiteknight let me fire up my winxp vm and see what I can see 00:05
kid51: build runs fine on my winxp box. No error 00:31
ttbot Parrot 708e44d3 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/84056 00:34
whiteknight blah, our behavior with exit() is still far less than optimal 00:36
so many places in the code just call exit() instead of something more suited like PANIC() or exit_fatal() or Parrot_x_exit() 00:37
nbrown cotto: I'm not pleased with how forgiving it is. I'll probably do more work on linux now that I resurected my linux vm 01:04
cotto: As for the scripting interface and parsing output, that's all I could think of too and I don't love that idea, but I guess we'll have to do it at some point 01:05
kid51_at_dinner github.com/parrot/parrot/issues/769 01:06
aloha (parrot/parrot) Issues opened : 769 ('make headerizer' fails to remove code from .h files when underlying functions have been deleted from .c files) by jkeenan : github.com/parrot/parrot/issues/769 01:10
dalek rrot: c77b11f | Whiteknight++ | src/ (7 files):
Replace several instances of the C exit() call with more controlled alternatives
 01:56
rrot: b1e9b39 | Whiteknight++ | / (9 files):
Delete the function exit_fatal. Replace it with a new Parrot_x_panic_and_exit (may be renamed). Add a new macro PARROT_FORCE_EXIT to use in place of the libc exit(i) routine, which should not be used on all platforms
rrot: e3ce02c | Whiteknight++ | / (16 files):
Replace the old do_panic function with a newer Parrot_x_panic_and_exit. Rename the previous Parrot_x_panic_and_exit with Parrot_x_force_error_exit
rrot: c9ad9c4 | Whiteknight++ | src/exit.c:
POD for Parrot_x_force_error_exit and Parrot_x_panic_and_exit
rrot: dbe4981 | Whiteknight++ | src/exit.c:
Update documentation in exit.c
rrot: 429329c | jkeenan++ | include/parrot/exit.h:
[codingstd] Add space between 'while' and subsequent open parenthesis.
 02:05
rrot: 698560f | Whiteknight++ | src/ops/core_ops.c:
bootstrap-ops, which I forgot to do after my last ops edit
 02:06
02:27 benabik joined
benabik ~~ 02:29
ttbot Parrot c77b11fc MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/84176 02:41
cotto nbrown, yeah. Feel free to think about it for a while, but the sooner something gets implemented, the less immediate work it'll entail. 03:04
We also need to be careful that the tests are minimally brittle. 03:08
ttbot Parrot 698560f3 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/84187 03:09
benabik ttbot needs to be cleaned out or shut up.
cotto anyone mind? 03:10
is it mj41 who takes care of ttbot?
sorear who owns ttbot?
nbrown cotto: sure, I'll probably try to write up something about it this weekend 03:20
I think one of the first steps will be to isolate the user interface and debugger logic. I took the first step with the commits that implemented the gdb return behavior, but I need to put together a real architecture to make sure I don't back myself into a corner 03:22
benabik aloha: ttbot? 03:23
aloha benabik: ttbot is see taptinder
benabik aloha: taptinder?
aloha benabik: taptinder is continues integration tool - taptinder.org . For Parrot project running on tt.taptinder.org/ and reporting build failures to #parrot channel as ttbot.
benabik cotto: github.com/mj41/TapTinder, so seems likely.
03:46 alester joined
dalek rrot: fda8f2e | petdance++ | frontend/pbc_merge/main.c:
localizing vars and fixed a const
 03:46
alester ping kid51 03:52
cotto nbrown, I'm glad you're giving some thought to proper architecture for m0-debugger. If you want to start a gist, wiki page, issue or whatever, go for it. 03:57
04:00 dduncan joined 04:02 dduncan left
dalek rrot: e640c08 | petdance++ | src/extend.c:
Remove bad HEADERIZER HFILE comment
 04:20
rrot: a6ec4a1 | petdance++ | include/parrot/exit.h:
reran headerizer
aloha (parrot/parrot) Issues closed : 769 ('make headerizer' fails to remove code from .h files when underlying functions have been deleted from .c files) by jkeenan : github.com/parrot/parrot/issues/769 04:31
ttbot Parrot fda8f2e7 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/84256 04:32
Parrot a6ec4a14 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/84267 05:02
05:32 japhb joined 06:00 alin joined 06:19 fperrad joined 06:58 brrt joined
dalek kudo/nom: 128e996 | moritz++ | / (2 files):
implement rindex with parrots new rindex opcodes

bump NQP revision to something that requires a new enough parrot		 07:20
kudo/nom: d61049f | moritz++ | src/core/Rat.pm:
improved Rat.Str by TimToady++
p: eee0fa5 | (Arne Skjærholt)++ | / (4 files):
First cut of handling explicitly managed strings.
 07:22
p: abef7b9 | (Arne Skjærholt)++ | src/6model/reprs/CStr.c:
Handle encoding parameter for CStr representation.
p: 6df554d | moritz++ | / (4 files):
Merge remote branch 'origin/cstr'
p: 17cc549 | moritz++ | tools/build/PARROT_REVISION:
bump parrot revision to get rindex ops
08:03 alin joined 08:18 lucian joined 08:37 cosimo joined 09:28 perlite joined 11:48 benabik joined
benabik ~~ 11:50
12:21 brrt joined 12:46 whiteknight joined 12:55 PacoAir joined
whiteknight good morning, #parrot 12:55
benabik o/ whiteknight 13:01
whiteknight good morning benabik. How are you doing today? 13:03
benabik I'm alright. A little sleep deprived. I should know better than to start working on something just before bed. 13:04
whiteknight I know that feeling. I spent way more time last night than I was planning to do on making our exit behaviors more sane
And I'm still not there yet
benabik I had to upload a diagram from class to the class wiki... Realized the photo I had taken (from the whiteboard) was unreadable. Decided to re-make it in OmniGraffle. Realized OmniGraffle 4's support for curved lines sucked. Upgraded to version 5. Created custom icons for file, folder, and cube... 13:06
whiteknight oh fun 13:07
benabik It kinda exploded from "I should upload this file" to "must create the perfect diagram"
whiteknight yeah, I'm familiar with those kinds of explosions 13:12
benabik I think it's part of what makes me a good programmer... But makes for very poor sleep habits.
"Just one more thing and it'll be perfect."
whiteknight I used to think WPF was a pretty decent framework for rich web-enabled applications 14:10
I was wrong
NotFound benabik: just buy a bigger whiteboard ;) 14:14
brrt wpf? 14:18
whiteknight brrt: wpf and silverlight were both like Microsoft's half-baked response to flash. They basically allowed you to run .NET applications in the browser 14:20
brrt oh, i did not know that last thing about wpf 14:21
odd
whiteknight actually, WPF was bigger than that, but one of it's features was the ability to download and run WPF applications from a browser in addition to running them natively
brrt hey, i know that feature 14:22
benabik NotFound: Sadly, we do have to share classrooms.
brrt it is called 'a bug' and is also known as activex :-p
whiteknight brrt: Yeah, very similar except it used .NET instead of native code. A little bit safer that way because of sandboxing and compartmentalization and stuff 14:23
brrt much like flash, java 14:24
also, what do people mean when they say 'rich client applications' 14:25
is google docs a rich client application?
NotFound brrt: It means "I want to get rich selling it"
brrt :-) true 14:26
NotFound Also, make Tim O'Really richer by buying its books about it. 14:27
brrt its funny how after +20 years of internet, javascript + dhtml is still often the best solution 14:28
NotFound Except when plain html is ;)
benabik brrt: Javascript hasn't existed for 20 years. It's only within the last few years that HTML+JS has been powerful enough to give you decent applications. 14:29
Flash and Java were decent solutions when they first came into existance.
brrt maybe not 20, but at least 10 14:30
i wonder what makes them 'undecent' solutions, now?
NotFound The first time I recompiled an applet with an updated version of the jdk, without changing a comma in the source, and it stopped working in the browser, I decied that java applets where not the way to go. 14:31
Many, many moos ago.
whiteknight www.250bpm.com/blog:4
NotFound Java just failed its promise of "compile once, run everywhere". 14:32
brrt i guess that is true
benabik Mostly the rise in power of the browsers. Why use this external framework when the browser itself gives what you need.
whiteknight: My brain is reading that as "I write bad C++ code, so I don't like it."
NotFound whiteknight: I read that document as "I made bad designs and blame the tool" 14:35
brrt i never realised that exceptions where 'dynamically scoped'
NotFound benabik: get out of my mind! 14:36
benabik Why is he using exceptions for local flow control? `if(condition1) handle_error1();` works just fine in C. "Error handling in constructors are hard without exceptions." Yes, yes they are. So use them. 14:37
Blah.
*C++
NotFound r = something(); if (r) throw A; catch (A).... Really? Looks like deliberate humor. 14:38
benabik And if he wants the catch near the original code, _use smaller try blocks_.
Re-implementing constructors and destructors means you've done something very wrong. 14:39
NotFound And he says that decoupling the exception handling is bad... You can't make a good exception handling design with such assumption. 14:40
The usual conclusion: you can write bad code in any language. 14:41
benabik C++ having well defined construction, destruction, and exception handling semantics is why I like it. RAII makes life simpler. 14:43
The decoupling between throwing and handling is the point. 90% of error handling is "cleanup resources and return an error". In C++ that becomes "ignore the exception". Destructors at block exit handle cleanup and the exception will pop up the stack on its own. 14:47
benabik will stop ranting now. 14:49
NotFound The thing some people have with destructors, is the classic about closing a handle. How can I report if close fails in a destructor? If you don't close explicitly and let the destructor do it, you just have declared that you don't care, plain and simple. 14:50
Is no the destructor job to report something you don't want to hear. 14:51
He's right in one thing: this is not only C++, every OO language with constructors and destructors has the same issue. 14:53
whiteknight destructors in particular are extremely problematic 14:56
benabik The big catch is what do you do when an exception occurs in a destructor being called because an exception happened. 14:57
C++ says "explode"
Which is semi-reasonable. 14:58
whiteknight Take the Parrot example. GC can get called at any point. Our GC gets called on allocation typically, which itself can be happening inside a constructor. This means GC can be triggered when user code is in an inconsistent state, and executes destructors outside of normal control flow in a place where errors cannot be handled the same as they are in normal code
benabik Ah, yeah. Finalizers in GC are tricky too.
whiteknight so when you're in a destructor you can't really throw an exception, because you're in a place without handlers, and you don't want to disrupt the "normal" control flow happening above GC, because the error isn't with that code 14:59
so you end up with an error condition that you either can't report at all, or that you have to jam into a cache and hope somebody checks it
benabik In a GC case, hope you can do something with it. 15:00
NotFound whiteknight: but... parrot destruction is always done by the GC; that is it's normal control flow.
benabik Because allocating memory while the GC is trying to free memory is... problematic.
whiteknight And assuming you try to report the error, do we tell the GC not to reclaim the memory, and leave an un-destructed zombie header floating in memory for...something, or do we free it anyway and tell the program that we've freed the object but it didn't destruct properly and by the way you can't get a reference to anything to try and resolve the issue
So maybe we disallow exceptions thrown in destructors, which is reasonable, but then there's absolutely no way to get back error information about a failure if it occurs 15:02
benabik Best thing I can think of is provide a log system. 15:03
This may be as simple as "print to STDERR"
15:03 dmalcolm joined
NotFound If you want a robust system, your objects must be robust, that's all. 15:04
benabik This is, BTW, why Java and C# have no custom finalizers. 15:05
NotFound Java has. 15:06
benabik Hm. Maybe C# does too. :-/
NotFound And they can cancel the destruction.
But java uses several kinds of weak references to handle such things. 15:07
benabik Weak refs are very useful in a GC.
whiteknight C# does have destructors, but there are a lot of restrictions on them and they aren't very popular
the IDisposable system is considered "best practice"
benabik Hm. "Any instances of classes that implement the finalize() method are often called finalizable objects. They will not be immediately reclaimed by the Java garbage collector when they are no longer referenced. Instead, the Java garbage collector appends the objects to a special queue for the finalization process."
NotFound Anyway, if you want to report problems during destruction you can. Just attach to the objects a reporting object, and send a message to it. 15:10
To the objects with such need, I mean, not to any object in the system. 15:11
benabik cotto: ping 15:14
NotFound A more critic comment: usually people that blame exceptions and decide to use C better than C++, later implement some sort of exception handling using longjmp, wich is a lot more incontrolable than C++ exceptions (Hey, parrot) ;) 15:15
benabik msg cotto ISTR you saying something about handling memory in M0 via sbrk. I have some issues with that idea. Starting with: are we going to implement the GC _inside_ M0? 15:17
aloha OK. I'll deliver the message.
benabik msg cotto We then get into things about brk not really being a good idea anymore. sbrk is limited to 4MB on OS X. mmap is the more fundamental operation on most systems these days. 15:18
aloha OK. I'll deliver the message.
benabik msg cotto As simple as we want M0 to be, it still needs to provide some features over the standard processor to make it worthwhile to abandon useful tools like "C compilers". I was expecting M0 to be a bootstrap step into our GC, control flow, and object system. 15:21
aloha OK. I'll deliver the message.
benabik Okay, I think I'm done.
15:28 JimmyZ joined 16:02 brrt left
benabik ~~ 16:37
Did my rants scare everyone away? 16:38
16:40 nopaste joined
benabik msg cotto Also: untyped registers make the GC more difficult. If there's no way to tell what registers are PMCs, how do we walk the call frames? 16:57
aloha OK. I'll deliver the message.
17:03 PacoAir joined 17:13 GodFather joined 17:27 lucian joined
cotto ~~ 17:44
benabik: are you suggesting that mmapping anonymous pages is better than sbrk? 18:03
That doesn't sound like a bad idea. I thought that sbrk was the fundamental operation, but mmap would be just fine, especially if there's a 4M limit on some platforms. 18:05
benabik cotto: First, I'm suggesting that M0 should use a real GC rather than manually dealing with memory. Second, sbrk is emulated by a large allocated buffer in at least some versions of OS X.
www.opensource.apple.com/source/Lib...ated/brk.c
Hm. Appears to be in the source for the most recent version too. 18:06
Yeah, 763.12 is the version of libc used in 10.7.3. 18:07
cotto hmmm 18:08
where the gc lives is a big question. 18:11
benabik Implemnting GC inside M0 will cause pain.
cotto yes 18:12
benabik Mostly because we won't have a toolchain anywhere near as nice as gcc for a long time, if ever, and the GC will probably want to interact directly with the OS often.
cotto and if it's part of the vm, that allows a gc that knows more about the underlying system
benabik Right.
cotto at the cost of more vm complexity
benabik Good complexity. 18:13
cotto that's not especially hard to argue
benabik If the VM is just a platform agnostic processor, then why bother?
whiteknight we do have a GC, and modifying it to work with M0 would be a lot less work than reimplementing the algorithm or even something more complex
cotto We ought to think twice before adding any complexity to M0, but that doesn't mean it can never happen. 18:14
It hasn't been much of an issue so far because we haven't been creating any gcables. 18:15
whiteknight We just have to weigh the costs and the benefits. We have a good GC with good performance, and there's no clear reason to rewrite in in M0
the one reason I can possibly think is to expose GC to JIT, and include it in optimization traces 18:16
but there's more than a little potential that this saves us nothing and hurts performance more
GC, for instance, typically won't get any benefit from having type-specific traces, because the vast majority of objects will be handled in an agnostic way 18:17
benabik The GC just needs to know "object" and "not object"
whiteknight or if we're doing a linear sweep through memory pools, there won't be any hot paths in destructors, because the objects are all jumbled together
benabik I honestly expected GC and object system to live outside M0.
whiteknight benabik: right, and now we do that by allocating them from separate pools
everything in the PMC pool is a PMC, everything in the string pool is a string, everything else is just dumb buffers 18:18
cotto that could work, especially since strings and PMCs will be the same thing 18:22
benabik Ideally strings and PMCs will be different REPRs in 6model land. :-D
My view of M0 is the minimum we need to be in a "sane VM" environment that supports a variety of native types (so HLLs can get 8/16/32 bit math), CPS, GC, and 6model. On top of that we can build PMCs, opcodes, exceptions, etc etc etc. 18:26
Oh. don't forget sane FFI.
whiteknight We've got three layers: M0, everything built on top of M0, and everything underneith on which M0 runs. GC, in my mind, falls squarely in the third category
We need some kind of substrate on which to build M0 18:27
benabik My "minimal" VM is somewhat heavyweight, but it's basically the minimum that isolates us from the outside world. Sadly, threads likely also have to live outside it. 18:28
We can build our carefully constructed ideals of HLLs, complex objects, exceptions, etc etc inside that realm. 18:32
Actually, not sadly. If our base-level VM is designed with threading in mind then everything inside the VM is implicitly thread-safe. This is a useful _feature_ 18:33
This is also a reason the GC should be outside the VM. It needs to know intimate details of threads and be able to cross the boundaries in ways we really want to forbid things inside the VM from doing. 18:34
cotto GC as part of the substrate is sensible. 18:35
benabik is partially just thinking out loud here. 18:36
cotto please, continue
What would the M0-level ops that care about GC need to look like? 18:37
benabik Various kinds of allocate and mark, I would think. Marking gets into interaction with the object system in funny ways though. 18:39
But we need an in-GC mark for in-VM created object systems.
cotto similar to VTABLE_mark of today's parrot 18:40
benabik Right.
cotto would that fall under 6model?
benabik My thoughts on M0's object model is entirely 6model focused. STABLES, REPRS, etc.
REPR has a gc_mark function in it, I think. 18:41
cotto ok
benabik But if we want to support REPRs created inside the VM, then we'd need an in-VM mark operation. 18:42
cotto I'm not sure that's necessary. REPRs are pretty low-level.
benabik If we don't have typed registers, every call frame needs a way to mark the PMCs stored in it.
cotto Would it work to require that if you want a custom repr, you have to write some C code?
benabik Probably. 18:43
inVM mark functions are probably insane anyway... Don't want to have to go back into the VM inside the GC. 18:44
(This is related to notions of finalization queues)
cotto that gets into the inner runloop problem 18:45
benabik Right.
Which we want dead dead dead dead dead.
cotto quite
benabik Finalization queues are an elegant solution to inVM destructors though. Work through them in the background as you can. 18:46
I wonder if we need any more support for weak references than just "hold a reference in an object and don't mark it".
So I guess M0 just needs allocation ops. Details of those somewhat depend on how we want to deal with objects and buffers and the like. I'm very much in favor of "everything's an object" to some extent. 18:50
18:50 alester joined
benabik The default REPR and HOW are "stupid buffer". 18:50
cotto including primitive numeric types? 18:51
benabik Er, no.
Prims are needed for speed.
But you don't need to allocate those. 18:52
cotto ok. When I hear "everything", I hear primitives in there too. 19:03
benabik Yeah, fair enough. I meant "everything we're using the allocate op".
cotto that could work
whiteknight I see our lowest-level VM core, the substrate below M0 as consisting of GC, threads/execution/runcore and not necessarily much els 19:17
else
Basically, we need something to provide memory allocation interfaces and then to execute M0 bytecode or whatever
and "where" the M0 gets executed is a threading concern 19:18
benabik Well, the GC needs to interact with the object system.
whiteknight If threads are at the lowest level, M0 can work with a much cleaner abstraction like Tasks (green threads) that automatically dispatch on an available execution thread
benabik M0 should not have "automatically dispatch"
whiteknight benabik: parts of the 6model plumbing can be at the lowest level too 19:19
benabik: maybe not by default. But we should be able to take a Task and dispatch it (A) on the current thread, (B) on a separate thread or (C) on first available
we can specify which
benabik whiteknight: I see all of those as things we can build on top of primitives M0 provides. If M0 gives us runloop per thread and messaging, we can "run now", "send message to run there", and "put on available queue" 19:24
But I'm quibbling over details, I suppose.
whiteknight benabik: there's nowhere for M0 to run in the first place if we don't have threads at the level below that 19:26
benabik "Runloop per thread, I said." :-D
19:26 crab2313 joined
whiteknight Once M0 gets moving, if it has handles to the threads and their queues, we can do everything else. It will have Tasks 19:26
benabik Have to add "spawn this as a new thread"
whiteknight well, not necessarily. We might have a fixed thread pool 19:27
benabik I'm quibbling that "threads don't necessarily have queues."
whiteknight or, on a single core machine or embedded machine, we might have only one "thread"
benabik M0 shouldn't deal with thread pools, etc, etc. Just give reasonable primitives to build these systems on.
whiteknight so we need an abstraction that says "dispatch this task, and do your best to either run it here or run it somewhere else or whatever is conveninent"
The real flexibility of the hybrid thread model is that the threads things run on are abstracted away 19:28
benabik Build the hybrid thread model on top of M0's actual threads. M0 provides the primitives, we build the system on top of it. 19:29
whiteknight I think we are saying almost exactly the same things, right past each other 19:33
benabik Probably.
Mostly I'm saying "M0 doesn't need the abstractions, it needs the primitives to build them". They're good abstractions though.
whiteknight I guess I'm saying that the threading system will be abstracted by default, whether M0 wants or needs it 19:34
so neener, neener.
benabik Heh.
whiteknight speaking of which, I really want to make a big push to get threading tested and merged to master shortly after 4.4 19:39
That gives us the maximum amount of time before the next supported release to get it tested, to start using it, to generate feedback, etc 19:40
We've got to get it sorted out on windows though, which is a concern
I may have to send out an email to parrot-dev, begging for favors 19:47
20:02 crab2313 left
cotto benabik: how would you split m0-6model in the what the VM supports directly and what userspace needs to do? 20:03
or whiteknight
whiteknight I'd be interested to hear what benabik thinks first 20:04
20:04 crab2313 joined
benabik My initial design would be making the 6model operations be M0 operations. At first glance they look sufficiently modular. 20:14
There may be some odd bootstrapping level where there are HOWs implemented in M0, but those would either be higher level only or have to operate through a cache. 20:16
Hm. 6model has some inferior runloop fun, I think. Perhaps M0 HOWs expose functions instead of opcodes. Hmmm... 20:17
whiteknight yeah, that's going to be the big problem, trying to separate out the stuff that uses runops and therefore needs to be at the M0 level 20:18
I would like to see as much of 6model as possible below the M0 level and provide primitives for working with the object model
benabik 6model operations needing to run M0 code isn't too much of a problem. If we make the opcodes that do that explicitly control flow operations like a function call. external HOWs just hijack the function call and return directly. 20:20
Replace an "inferior runloop" with a function call and all's good. It may be a _special kind_ of function call so the C HOWs don't have to deal with the allocations and so forth. 20:21
whiteknight right 20:25
benabik If the REPR is all C, then we just have to worry about the other operations in the STable. 20:34
20:38 lucian joined
benabik find_method, type_check, de-containerize, and boolification. If those are all explicitly "may be a function call" then we're set. Everything else is part of the REPR. 20:38
cotto benabik: can you start a wiki page or gist for planning this? 20:40
benabik Erm. 20:41
No, it gets more complex than that. Many of Rakudo's REPR operations call VTABLES. Hm. 20:43
Wait, maybe those are all on our basic types, not P6 objects. 20:44
Yes. REPR operations call methods on the HOW. I see now. 20:46
hmmmm 20:47
PerlJam benabik: have you read jnthn's blog? 6guts.wordpress.com 20:50
you might want to look through past articles for some high-level information about how things fit together.
for instance, 6guts.wordpress.com/2010/10/15/slid...ymorphism/ 20:51
benabik PerlJam: I have been, yes. It's not all on the top of my head. I forgot the details of REPR and HOW interaction. Which are fairly low level. 20:53
Despite the nice clear conceptual devision between them, the P6opaque REPR calls into the HOW. Which means that REPR ops can't be guaranteed to be atomic operations from the point of view of the VM. 20:55
Coke do we care about atomicity at this level? 20:56
benabik Where "atomic" means "not calling back into the VM"
PerlJam depends on where threading and such lives
benabik I meant atomic as in "one step of the VM". 20:57
Blarg. This needs more thought. I did say "initial design" to start. It just got scrapped faster than expected. :-/ 21:01
But I have to go. \\o
PerlJam benabik: cheers 21:02
21:04 rindolf joined
rindolf Hi all. After I added "parrot" to the plugins list of github.com/MarcWeber/vim-addon-manager , it installed something horrible out-of-date - "" Based on Parrot 0.10". 21:05
21:24 crab2313 left 21:34 benabik joined
dalek nxed/builtinexpr: efe0605 | NotFound++ | winxedst2.winxed:
builtin expr first test, with string cast
 22:07
Coke rindolf: we don't tend to keep our vim plugin up to date, I do not think. 22:28
(also, I have no idea who marc weber is.)
cotto benabik: I'd like to bounce something off you for a sanity check: 23:16
thinking about gc-related M0 ops, would gc_alloc and gc_mark provide a everything that m0 code would need or are there edge cases to consider that those don't cover?
That and sys_alloc, sys_free and copy_mem would be the bulk of M0 code's interface to memory. 23:45
Under the surface all memory would live in the same set of contiguous anonymous pages, but the VM would know which offsets contain GC-controlled memory and could look for references to them.
23:53 whiteknight joined
whiteknight good evening, #parrot 23:53
cotto hio whiteknight
whiteknight I had to take the battery out of my mouse to replace the one from my son's motorized Thomas the Tank Engine toy, so my productivity tonight is going to be decreased 23:54
or maybe increased, if I can't surf the internet so much 23:55
I'll just have to download twice as many pictures of cats tomorrow night

Powered by Cro and the Raku® Programming Language.

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

Thank you!