Camelia, the Perl 6 bug

IRC log for #parrot, 2012-05-10

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 whiteknight something has to be broked with that smoker
00:00 kid51 http://tt.taptinder.org/buildstatus/parrot/master
00:01 kid51 Or else, something is broken on Win32 build
00:01 cotto ~~
00:02 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:05 whiteknight let me fire up my winxp vm and see what I can see
00:31 whiteknight kid51: build runs fine on my winxp box. No error
00:34 ttbot Parrot 708e44d3 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/84056
00:36 whiteknight blah, our behavior with exit() is still far less than optimal
00:37 whiteknight so many places in the code just call exit() instead of something more suited like PANIC() or exit_fatal() or Parrot_x_exit()
01:04 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:05 nbrown 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:06 kid51_at_dinner https://github.com/parrot/parrot/issues/769
01:10 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 : https://github.com/parrot/parrot/issues/769
01:56 dalek parrot: c77b11f | Whiteknight++ | src/ (7 files):
01:56 dalek parrot: Replace several instances of the C exit() call with more controlled alternatives
01:56 dalek parrot: review: https://github.com/parrot/parrot/commit/c77b11fc5e
01:56 dalek parrot: b1e9b39 | Whiteknight++ | / (9 files):
01:56 dalek parrot: 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
01:56 dalek parrot: review: https://github.com/parrot/parrot/commit/b1e9b39f95
01:56 dalek parrot: e3ce02c | Whiteknight++ | / (16 files):
01:56 dalek parrot: 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
01:56 dalek parrot: review: https://github.com/parrot/parrot/commit/e3ce02c87f
01:56 dalek parrot: c9ad9c4 | Whiteknight++ | src/exit.c:
01:56 dalek parrot: POD for Parrot_x_force_error_exit and Parrot_x_panic_and_exit
01:56 dalek parrot: review: https://github.com/parrot/parrot/commit/c9ad9c4f02
01:56 dalek parrot: dbe4981 | Whiteknight++ | src/exit.c:
01:56 dalek parrot: Update documentation in exit.c
01:56 dalek parrot: review: https://github.com/parrot/parrot/commit/dbe498102e
02:05 dalek parrot: 429329c | jkeenan++ | include/parrot/exit.h:
02:05 dalek parrot: [codingstd] Add space between 'while' and subsequent open parenthesis.
02:05 dalek parrot: review: https://github.com/parrot/parrot/commit/429329c01f
02:06 dalek parrot: 698560f | Whiteknight++ | src/ops/core_ops.c:
02:06 dalek parrot: bootstrap-ops, which I forgot to do after my last ops edit
02:06 dalek parrot: review: https://github.com/parrot/parrot/commit/698560f327
02:27 benabik joined #parrot
02:29 benabik ~~
02:41 ttbot Parrot c77b11fc MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/84176
03:04 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:08 cotto We also need to be careful that the tests are minimally brittle.
03:09 ttbot Parrot 698560f3 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/84187
03:09 benabik ttbot needs to be cleaned out or shut up.
03:10 cotto anyone mind?
03:10 cotto is it mj41 who takes care of ttbot?
03:10 sorear who owns ttbot?
03:20 nbrown cotto: sure, I'll probably try to write up something about it this weekend
03:22 nbrown 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:23 benabik aloha: ttbot?
03:23 aloha benabik: ttbot is see taptinder
03:23 benabik aloha: taptinder?
03:23 aloha benabik: taptinder is continues integration tool - http://taptinder.org . For Parrot project running on http://tt.taptinder.org/ and reporting build failures to #parrot channel as ttbot.
03:23 benabik cotto: github.com/mj41/TapTinder, so seems likely.
03:46 alester joined #parrot
03:46 dalek parrot: fda8f2e | petdance++ | frontend/pbc_merge/main.c:
03:46 dalek parrot: localizing vars and fixed a const
03:46 dalek parrot: review: https://github.com/parrot/parrot/commit/fda8f2e719
03:52 alester ping kid51
03:57 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.
04:00 dduncan joined #parrot
04:02 dduncan left #parrot
04:20 dalek parrot: e640c08 | petdance++ | src/extend.c:
04:20 dalek parrot: Remove bad HEADERIZER HFILE comment
04:20 dalek parrot: review: https://github.com/parrot/parrot/commit/e640c08484
04:20 dalek parrot: a6ec4a1 | petdance++ | include/parrot/exit.h:
04:20 dalek parrot: reran headerizer
04:20 dalek parrot: review: https://github.com/parrot/parrot/commit/a6ec4a14eb
04:31 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 : https://github.com/parrot/parrot/issues/769
04:32 ttbot Parrot fda8f2e7 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/84256
05:02 ttbot Parrot a6ec4a14 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/84267
05:32 japhb joined #parrot
06:00 alin joined #parrot
06:19 fperrad joined #parrot
06:58 brrt joined #parrot
07:20 dalek rakudo/nom: 128e996 | moritz++ | / (2 files):
07:20 dalek rakudo/nom: implement rindex with parrots new rindex opcodes
07:20 dalek rakudo/nom:
07:20 dalek rakudo/nom: bump NQP revision to something that requires a new enough parrot
07:20 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/128e996df2
07:20 dalek rakudo/nom: d61049f | moritz++ | src/core/Rat.pm:
07:20 dalek rakudo/nom: improved Rat.Str by TimToady++
07:21 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d61049ff52
07:22 dalek nqp: eee0fa5 | (Arne Skjærholt)++ | / (4 files):
07:22 dalek nqp: First cut of handling explicitly managed strings.
07:22 dalek nqp: review: https://github.com/perl6/nqp/commit/eee0fa501f
07:22 dalek nqp: abef7b9 | (Arne Skjærholt)++ | src/6model/reprs/CStr.c:
07:22 dalek nqp: Handle encoding parameter for CStr representation.
07:22 dalek nqp: review: https://github.com/perl6/nqp/commit/abef7b968b
07:22 dalek nqp: 6df554d | moritz++ | / (4 files):
07:22 dalek nqp: Merge remote branch 'origin/cstr'
07:22 dalek nqp: review: https://github.com/perl6/nqp/commit/6df554d2cb
07:22 dalek nqp: 17cc549 | moritz++ | tools/build/PARROT_REVISION:
07:22 dalek nqp: bump parrot revision to get rindex ops
07:22 dalek nqp: review: https://github.com/perl6/nqp/commit/17cc549e42
08:03 alin joined #parrot
08:18 lucian joined #parrot
08:37 cosimo joined #parrot
09:28 perlite joined #parrot
11:48 benabik joined #parrot
11:50 benabik ~~
12:21 brrt joined #parrot
12:46 whiteknight joined #parrot
12:55 PacoAir joined #parrot
12:55 whiteknight good morning, #parrot
13:01 benabik o/ whiteknight
13:03 whiteknight good morning benabik. How are you doing today?
13:04 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
13:04 whiteknight And I'm still not there yet
13:06 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:07 whiteknight oh fun
13:07 benabik It kinda exploded from "I should upload this file" to "must create the perfect diagram"
13:12 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.
13:12 benabik "Just one more thing and it'll be perfect."
14:10 whiteknight I used to think WPF was a pretty decent framework for rich web-enabled applications
14:10 whiteknight I was wrong
14:14 NotFound benabik: just buy a bigger whiteboard ;)
14:18 brrt wpf?
14:20 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:21 brrt oh, i did not know that last thing about wpf
14:21 brrt odd
14:21 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
14:22 brrt hey, i know that feature
14:22 benabik NotFound: Sadly, we do have to share classrooms.
14:22 brrt it is called 'a bug' and is also known as activex :-p
14:23 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:24 brrt much like flash, java
14:25 brrt also, what do people mean when they say 'rich client applications'
14:25 brrt is google docs a rich client application?
14:25 NotFound brrt: It means "I want to get rich selling it"
14:26 brrt :-) true
14:27 NotFound Also, make Tim O'Really richer by buying its books about it.
14:28 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 ;)
14:29 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 benabik Flash and Java were decent solutions when they first came into existance.
14:30 brrt maybe not 20, but at least 10
14:30 brrt i wonder what makes them 'undecent' solutions, now?
14:31 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 NotFound Many, many moos ago.
14:31 whiteknight http://www.250bpm.com/blog:4
14:32 NotFound Java just failed its promise of "compile once, run everywhere".
14:32 brrt i guess that is true
14:32 benabik Mostly the rise in power of the browsers.  Why use this external framework when the browser itself gives what you need.
14:32 benabik whiteknight: My brain is reading that as "I write bad C++ code, so I don't like it."
14:35 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'
14:36 NotFound benabik: get out of my mind!
14:37 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 benabik Blah.
14:37 benabik *C++
14:38 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_.
14:39 benabik Re-implementing constructors and destructors means you've done something very wrong.
14:40 NotFound And he says that decoupling the exception handling is bad... You can't make a good exception handling design with such assumption.
14:41 NotFound The usual conclusion: you can write bad code in any language.
14:43 benabik C++ having well defined construction, destruction, and exception handling semantics is why I like it.  RAII makes life simpler.
14:47 benabik 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:49 * benabik will stop ranting now.
14:50 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:51 NotFound Is no the destructor job to report something you don't want to hear.
14:53 NotFound He's right in one thing: this is not only C++, every OO language with constructors and destructors has the same issue.
14:56 whiteknight destructors in particular are extremely problematic
14:57 benabik The big catch is what do you do when an exception occurs in a destructor being called because an exception happened.
14:57 benabik C++ says "explode"
14:58 benabik 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
14:58 benabik Ah, yeah.  Finalizers in GC are tricky too.
14:59 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 whiteknight 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
15:00 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.
15:00 benabik Because allocating memory while the GC is trying to free memory is...  problematic.
15:00 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
15:02 whiteknight 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:03 benabik Best thing I can think of is provide a log system.
15:03 benabik This may be as simple as "print to STDERR"
15:03 dmalcolm joined #parrot
15:04 NotFound If you want a robust system, your objects must be robust, that's all.
15:05 benabik This is, BTW, why Java and C# have no custom finalizers.
15:06 NotFound Java has.
15:06 benabik Hm.  Maybe C# does too.  :-/
15:06 NotFound And they can cancel the destruction.
15:07 NotFound But java uses several kinds of weak references to handle such things.
15:07 benabik Weak refs are very useful in a GC.
15:07 whiteknight C# does have destructors, but there are a lot of restrictions on them and they aren't very popular
15:07 whiteknight the IDisposable system is considered "best practice"
15:07 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."
15:10 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:11 NotFound To the objects with such need, I mean, not to any object in the system.
15:14 benabik cotto: ping
15:15 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:17 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.
15:18 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.
15:21 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.
15:21 benabik Okay, I think I'm done.
15:28 JimmyZ joined #parrot
16:02 brrt left #parrot
16:37 benabik ~~
16:38 benabik Did my rants scare everyone away?
16:40 nopaste joined #parrot
16:57 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 #parrot
17:13 GodFather joined #parrot
17:27 lucian joined #parrot
17:44 cotto ~~
18:03 cotto benabik: are you suggesting that mmapping anonymous pages is better than sbrk?
18:05 cotto 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.
18:05 benabik http://www.opensource.apple.com/sou​rce/Libc/Libc-763.12/emulated/brk.c
18:06 benabik Hm.  Appears to be in the source for the most recent version too.
18:07 benabik Yeah, 763.12 is the version of libc used in 10.7.3.
18:08 cotto hmmm
18:11 cotto where the gc lives is a big question.
18:11 benabik Implemnting GC inside M0 will cause pain.
18:12 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.
18:12 cotto and if it's part of the vm, that allows a gc that knows more about the underlying system
18:12 benabik Right.
18:12 cotto at the cost of more vm complexity
18:13 benabik Good complexity.
18:13 cotto that's not especially hard to argue
18:13 benabik If the VM is just a platform agnostic processor, then why bother?
18:13 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
18:14 cotto We ought to think twice before adding any complexity to M0, but that doesn't mean it can never happen.
18:15 cotto 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
18:16 whiteknight the one reason I can possibly think is to expose GC to JIT, and include it in optimization traces
18:16 whiteknight but there's more than a little potential that this saves us nothing and hurts performance more
18:17 whiteknight 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"
18:17 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
18:17 benabik I honestly expected GC and object system to live outside M0.
18:17 whiteknight benabik: right, and now we do that by allocating them from separate pools
18:18 whiteknight everything in the PMC pool is a PMC, everything in the string pool is a string, everything else is just dumb buffers
18:22 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
18:26 benabik 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 benabik Oh.  don't forget sane FFI.
18:26 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
18:27 whiteknight We need some kind of substrate on which to build M0
18:28 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:32 benabik We can build our carefully constructed ideals of HLLs, complex objects, exceptions, etc etc inside that realm.
18:33 benabik 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:34 benabik 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:35 cotto GC as part of the substrate is sensible.
18:36 * benabik is partially just thinking out loud here.
18:36 cotto please, continue
18:37 cotto What would the M0-level ops that care about GC need to look like?
18:39 benabik Various kinds of allocate and mark, I would think.  Marking gets into interaction with the object system in funny ways though.
18:39 benabik But we need an in-GC mark for in-VM created object systems.
18:40 cotto similar to VTABLE_mark of today's parrot
18:40 benabik Right.
18:40 cotto would that fall under 6model?
18:40 benabik My thoughts on M0's object model is entirely 6model focused.  STABLES, REPRS, etc.
18:41 benabik REPR has a gc_mark function in it, I think.
18:41 cotto ok
18:42 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.
18:42 benabik If we don't have typed registers, every call frame needs a way to mark the PMCs stored in it.
18:42 cotto Would it work to require that if you want a custom repr, you have to write some C code?
18:43 benabik Probably.
18:44 benabik inVM mark functions are probably insane anyway...  Don't want to have to go back into the VM inside the GC.
18:44 benabik (This is related to notions of finalization queues)
18:45 cotto that gets into the inner runloop problem
18:45 benabik Right.
18:45 benabik Which we want dead dead dead dead dead.
18:45 cotto quite
18:46 benabik Finalization queues are an elegant solution to inVM destructors though.  Work through them in the background as you can.
18:46 benabik I wonder if we need any more support for weak references than just "hold a reference in an object and don't mark it".
18:50 benabik 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 alester joined #parrot
18:50 benabik The default REPR and HOW are "stupid buffer".
18:51 cotto including primitive numeric types?
18:51 benabik Er, no.
18:51 benabik Prims are needed for speed.
18:52 benabik But you don't need to allocate those.
19:03 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".
19:03 cotto that could work
19:17 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 whiteknight else
19:17 whiteknight Basically, we need something to provide memory allocation interfaces and then to execute M0 bytecode or whatever
19:18 whiteknight and "where" the M0 gets executed is a threading concern
19:18 benabik Well, the GC needs to interact with the object system.
19:18 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
19:18 benabik M0 should not have "automatically dispatch"
19:19 whiteknight benabik: parts of the 6model plumbing can be at the lowest level too
19:19 whiteknight 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
19:19 whiteknight we can specify which
19:24 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 benabik But I'm quibbling over details, I suppose.
19:26 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 #parrot
19:26 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"
19:27 whiteknight well, not necessarily. We might have a fixed thread pool
19:27 benabik I'm quibbling that "threads don't necessarily have queues."
19:27 whiteknight or, on a single core machine or embedded machine, we might have only one "thread"
19:27 benabik M0 shouldn't deal with thread pools, etc, etc.  Just give reasonable primitives to build these systems on.
19:27 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"
19:28 whiteknight The real flexibility of the hybrid thread model is that the threads things run on are abstracted away
19:29 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:33 whiteknight I think we are saying almost exactly the same things, right past each other
19:33 benabik Probably.
19:33 benabik Mostly I'm saying "M0 doesn't need the abstractions, it needs the primitives to build them".  They're good abstractions though.
19:34 whiteknight I guess I'm saying that the threading system will be abstracted by default, whether M0 wants or needs it
19:34 whiteknight so neener, neener.
19:34 benabik Heh.
19:39 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:40 whiteknight 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 whiteknight We've got to get it sorted out on windows though, which is a concern
19:47 whiteknight I may have to send out an email to parrot-dev, begging for favors
20:02 crab2313 left #parrot
20:03 cotto benabik: how would you split m0-6model in the what the VM supports directly and what userspace needs to do?
20:03 cotto or whiteknight
20:04 whiteknight I'd be interested to hear what benabik thinks first
20:04 crab2313 joined #parrot
20:14 benabik My initial design would be making the 6model operations be M0 operations.  At first glance they look sufficiently modular.
20:16 benabik 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:17 benabik Hm.  6model has some inferior runloop fun, I think.  Perhaps M0 HOWs expose functions instead of opcodes.  Hmmm...
20:18 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 whiteknight I would like to see as much of 6model as possible below the M0 level and provide primitives for working with the object model
20:20 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:21 benabik 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:25 whiteknight right
20:34 benabik If the REPR is all C, then we just have to worry about the other operations in the STable.
20:38 lucian joined #parrot
20:38 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:40 cotto benabik: can you start a wiki page or gist for planning this?
20:41 benabik Erm.
20:43 benabik No, it gets more complex than that.  Many of Rakudo's REPR operations call VTABLES.  Hm.
20:44 benabik Wait, maybe those are all on our basic types, not P6 objects.
20:46 benabik Yes.  REPR operations call methods on the HOW.  I see now.
20:47 benabik hmmmm
20:50 PerlJam benabik: have you read jnthn's blog?  6guts.wordpress.com
20:50 PerlJam you might want to look through past articles for some high-level information about how things fit together.
20:51 PerlJam for instance, http://6guts.wordpress.com/2010/10/15/slides-a​nd-a-few-words-on-representation-polymorphism/
20:53 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:55 benabik 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:56 Coke do we care about atomicity at this level?
20:56 benabik Where "atomic" means "not calling back into the VM"
20:56 PerlJam depends on where threading and such lives
20:57 benabik I meant atomic as in "one step of the VM".
21:01 benabik Blarg.  This needs more thought.  I did say "initial design" to start.  It just got scrapped faster than expected.  :-/
21:01 benabik But I have to go.  \o
21:02 PerlJam benabik: cheers
21:04 rindolf joined #parrot
21:05 rindolf Hi all. After I added "parrot" to the plugins list of https://github.com/MarcWeber/vim-addon-manager , it installed something horrible out-of-date - "" Based on Parrot 0.10".
21:24 crab2313 left #parrot
21:34 benabik joined #parrot
22:07 dalek winxed/builtinexpr: efe0605 | NotFound++ | winxedst2.winxed:
22:07 dalek winxed/builtinexpr: builtin expr first test, with string cast
22:07 dalek winxed/builtinexpr: review: https://github.com/NotFoun​d/winxed/commit/efe0605951
22:28 Coke rindolf: we don't tend to keep our vim plugin up to date, I do not think.
22:28 Coke (also, I have no idea who marc weber is.)
23:16 cotto benabik: I'd like to bounce something off you for a sanity check:
23:16 cotto 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?
23:45 cotto That and sys_alloc, sys_free and copy_mem would be the bulk of M0 code's interface to memory.
23:45 cotto 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 #parrot
23:53 whiteknight good evening, #parrot
23:53 cotto hio whiteknight
23:54 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:55 whiteknight or maybe increased, if I can't surf the internet so much
23:55 whiteknight I'll just have to download twice as many pictures of cats tomorrow night

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced