Parrot 4.4.0 "Banana Fanna Fo Ferret" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 3 June 2012.
00:25 arnsholt_ joined
dalek rrot/whiteknight/io_cleanup1: e0011ca | Whiteknight++ | src/io/ (2 files):
StringHandle defaults to ASCII encoding if not otherwise specified. The total_size of the stringhandle is bufused, not _buflen. Don't bother allocating extra room in the string buffer for partial multi-byte characters, because the buffering logic ensures they don't exist.
 00:31
rrot/whiteknight/io_cleanup1: f38818e | Whiteknight++ | src/io/api.c:
In Parrot_io_readline_s, make sure to actually update the buffer if we've added it. This reclaims several more tests where the null buffer was causing failed assertions.
rrot/whiteknight/io_cleanup1: 0c26862 | Whiteknight++ | / (3 files):
Add a new PIO_VF_PATH_NOT_REQUIRED to flag types that can be opened without an explicit path provided. Use this flag to reclaim two more StringHandle tests.
rrot/whiteknight/io_cleanup1: df032cc | Whiteknight++ | / (4 files):
Fix the remaining stringhandle.t failures. Most fixes come from better handling of encodings. One test was absolutely wrong and needed to be updated. Also, fix two uses of the UNUSED macro, pointed out by NotFound++
rrot/whiteknight/io_cleanup1: 8531225 | Whiteknight++ | src/io/ (3 files):
Rearrange some buffer macros. Implement Parrot_io_tell to match the old behavior (which I don't think is right, but whatever)
rrot/whiteknight/io_cleanup1: 909bec2 | Whiteknight++ | / (5 files):
Implement seek. Right now, bypass buffers and always seek directly to disk. This is brain-dead but we can fix it later. Also, fix some codestd problems noticed by NotFound++
rrot/whiteknight/io_cleanup1: 0192161 | Whiteknight++ | src/ (4 files):
Don't buffer r/w handles, for now. When doing seek on a buffered handle, account for the data in the buffer. Make sure to return the correct thing from seek.
 01:11
whiteknight blah, I'm out of brain power for tonight
bebac tomorrow
01:39 benabik joined
dalek rrot: 5a208a7 | alvis++ | docs/project/release_manager_guide.pod:
Added reini (Jul 17, 2012 - 4.6.0) and whiteknight (Aug 21, 2012 - 4.7.0) as release mangers.
 04:01
04:02 benabik joined
dalek kudo/map2: 6119246 | pmichaud++ | src/core/MapIter.pm:
Short-circuit 'redo' label in MapIter.reduce, and start a new branch for the MapIter refactor.
 04:55
aloha (parrot/parrot) Issues opened : 782 ( /usr/local/lib/parrot/4.4.0-devel/parrot_config.o: Permission denied) by rurban : github.com/parrot/parrot/issues/782 04:57
dalek kudo/nom: b4a3407 | pmichaud++ | README:
Typo reported by diakopter++: "prerequisits" -> "prerequisites".
 05:04
kudo/map2: 87b0441 | pmichaud++ | src/core/ListIter.pm:
Code cleanup: Replace some nqp::ops with things the inliner can now do for us.
 05:32
kudo/map2: 42659b1 | pmichaud++ | src/core/ (2 files):
Remove (basically unused) :$sink option to .reify(). Sinks will be refactored somewhat differently.
kudo/map2: 50acb53 | pmichaud++ | src/core/ (4 files):
Refactor $!nextiter handling for List and ListIter.
kudo/map2: b409b83 | pmichaud++ | src/core/ (2 files):
Refactor NEXT and LAST handling in MapIter ...

  ...because using the 'for' construct inside of MapIter.reify() just
feels so very wrong.		 05:55
05:57 fperrad joined 07:02 brrt joined 08:11 kjs joined
dalek kudo/nom: a441882 | moritz++ | / (2 files):
basic module loading tracing

enabled with env variable RAKUDO_MODULE_DEBUG=1		 10:20
10:23 kid51 joined 10:59 kjs joined 11:14 JimmyZ joined
dalek rrot/m0: 9d4e705 | jimmy++ | src/m0/c/m0_ops.c:
improve op print_i and print_n output a bit
 11:23
kjs JimmyZ: is it possible to print negative numbers with print_i? 11:26
JimmyZ kjs: yep, ./run_m1.sh t/t3.m1 11:27
kjs ok, just wondering, it's a cast to unsigned long
unsigned dont store neg. nrs no?
JimmyZ kjs: I don't know why there is a unsigned cast too, but since it can print negative numbers, I don't care why. :P 11:29
kjs JimmyZ: I was planning to add splint directives to the source code of M1. Could you integrate the invocation of splint in the makefile? 11:30
if splint's installed 11:31
JimmyZ kjs: I think I can 11:33
kjs great, thanks 11:34
JimmyZ kjs: I didn't use splint before :P
kjs ok it's v easy. just "splint <file>" 11:35
dalek : 424d294 | jimmy++ | Makefile:
integrate the invocation of splint, mostly stealed from parrot
 12:03
12:10 mj41 joined 12:13 ttbot joined 12:20 JimmyZ joined 12:23 kjs joined
JimmyZ kjs: I just add it 12:24
kjs great, thanks 12:25
jimmy++
JimmyZ kjs: NP :P 12:26
12:56 PacoAir joined 12:59 whiteknight joined
whiteknight good morning, #parrot 13:00
moritz \\o whiteknight 13:01
kjs good afternoon
whiteknight hello moritz, kjs, how are you two doing todaY? 13:02
13:02 bluescreen joined
kjs whiteknight: good thanks. what about yourself? 13:02
moritz tired. ENOTENOUGHSLEEP.
brrt hey, hello
sleep is important, man
whiteknight kjs: doing very well, thanks
brrt: good morning. How's mod_parrot and things? 13:03
moritz brrt: I know. You have to tell my wife and daughter :-)
brrt haven't done much about it since yesterday evening really
busy busy, everybody wants me to do their statistics assignments, which I find hard to say no because I like data
kjs whiteknight: I'm >< this close to generating correct M0 code for a function call and return. blocker at the moment is that it's not possible to generate a generally correct solution. 13:04
brrt notfound mailed me bytebuffer
kjs > < this close.
brrt which Does What I Want w/regards to passing pointers
but I have yet to test it
whiteknight I suspect we need to add the get_pointer vtable to String PMC to do what you want too, but that's ugly in a lot of ways 13:05
Coke kjs: I'm glad you're identifying these issues, but it seems odd to me that no one noticed this yet. ;)
whiteknight ByteBuffer really does what we need 90% of the time
kjs Coke: nobody tried I suppose!
whiteknight Coke: Yeah, so many of these issues aren't identified until somebody puts together an implementation. Remember how much the synopses needed to change as Rakudo and Pugs made progress? 13:06
brrt what do you think about me thinking that compreg /should/ return an error from the api, if not from parrot itself
whiteknight brrt: I am warming up to the idea. I would want to hear from cotto before pulling the trigger.
brrt ok, i have only a small horse in the race 13:07
whiteknight It's going to require some changes to Winxed, Rosella, NQP and Rakudo. That isn't a blocker, but is worth remembering
brrt .. its big, though
i should also take a look at my planned schedule and see where I am 13:08
13:08 Psyche^ joined
moritz fwiw in rakudo we usually assume that compreg succeeds 13:09
whiteknight brrt: Yes, let's have a little meeting later to go over the schedule
moritz exception in eval(), where we check the result 13:10
Coke if compreg PIR fails, parrot is in a lot of trouble.
moritz *except
Coke (at least in today's world)
whiteknight Coke: The question is what we do if compreg doesn't have a compiler with the given name. Right now we return PMCNULL which does raise something of a semi-predicate problem (though it's hard to imagine cases where somebody would purposefully register PMCNULL as a compiler)
moritz which is I don't have a problem with the current approach 13:11
13:12 crab2313 joined
Coke parrot's opcodes are a hodgepodge of null vs. exception, no? 13:12
at the opcode level, null seems a better solution. 13:13
brrt ... returning null is in itself fair enough
whiteknight I know the Rakudo folks have expressed a general preference that opcodes use null instead of exceptions, for performance reasons
moritz have we? :-) 13:14
whiteknight but compreg is infrequently used to the point that exceptions there shouldn't tank an application
AND. there's the option that we only throw the exception from the C-level Parrot_api_get_compiler routine, which wouldn't affect Rakudo almost at all
brrt acting like every call to Parrot_api_get_compiler(interp, "foobarbage") is 'succesfull' is a bit more problem
whiteknight moritz: pmichaud and timtoady had mentioned it was a better idea, in a vague sort of way 13:15
brrt anyway, this early evening I'll be busy today
what about later this evening?
whiteknight brrt: Right, so we can throw an exception there, but then the Parrot_api_get_compiler routine has different semantics from the compreg_p_s opcode (which, again, might not be a problem)
brrt I have no moral issues against having different behavior between compreg() and an api call 13:16
it is why we have apis
moritz but isn't returning NULL easier for the C API anyway?
brrt if it returned NULL, yes
it returns PMCNULL
which is another symbol
of which I'm not even sure is imported 13:17
moritz so
any objection to returning NULL from C API?
whiteknight brrt: like I said, I'm on the fence about it. I just want to hear what cotto has to say
moritz that looks like the best short term solutioni to me
brrt its not unfair
but there is already another 'failure signaling mode', which is the return value 13:18
whiteknight moritz: We do have to keep the API consistent. No other API routines return just NULL
well, not the ones that expect a PMC to be returned
moritz whiteknight: hm, ok
brrt for me as an api user primarily, it is a no-brainer really 13:19
whiteknight The API routines all return a boolean so they can be chained if (foo() && bar() && baz() ...), so throwing the exception and breaking the chain is probably the best option
Coke the API doesn't have to return what the opcodes do. 13:20
whiteknight this is true, which is why the exception here is possible without also needing to update the opcode
Coke so if the C returns NULL and the opcode returns PMCNULL, is there again no problem? 13:21
exceptions from C make less sense than sentinel values. no?
exceptions in bytecode make more sense.
whiteknight right, but my point to moritz earlier is that all other API routines return PMCNULL when a PMC is expected, and I would much prefer not to break that consistency
Coke: api routines catch exceptions, store them and return false 13:22
brrt more to the point, i expect one to pass PMCNULL to parrot and have there be no 'problem', while passing NULL might as well
whiteknight At that point, if we have an unhandled exception, there's nothing for libparrot to do anyway but return control to the parent application for processing
brrt: Yes, most API routines that take a PMC* will accept NULL and automatically turn it into PMCNULL 13:23
so we're covered on input
brrt I see
whiteknight brrt: PMCNULL is accessible through Parrot_api_pmc_null (github.com/parrot/parrot/blob/mast...mc.c#L116) if you need it. Clunky, but possible 13:24
brrt clunky, yes
not doing anything is fortunately easy 13:25
whiteknight It doesn't look like we have an easy test for testing whether a PMC is null. It might be a good idea to start adding a series of helper methods for things like that
brrt well, Parrot_api_pmc_is_null is simple enough to implement
what other API methods return PMCNULL rather than failing?
whiteknight depends what you mean by fail 13:28
Most API routines are very very thin wrappers around the internal worker functions which do the work. Parrot_api_get_compiler is no different 13:29
brrt hmm, thats the essential question, isn't it
whats failure here
whiteknight is not finding a compiler by the specified name an "exceptional" event, or is it something we can test, find an invalid value, and try something else? 13:30
That is, if we look for a compiler to we expect to get it or can we live with it not being there? 13:31
For the case of compilers, maybe it is something so rare and so fundamental that we just need to have it or else
Coke fundamental. 13:33
brrt yeah, i agree with the fundamental thing
Coke but I don't think that forces the API to throw an exception in this case. 13:34
brrt ... suppose we deprecate PIR
Coke which notfound has already done. ;)
brrt or, more realistically
we depecrate PASM
and some compiler still relies on it
whiteknight Coke already did that :)
brrt not having it should reasonably be screamed all over 13:35
Coke whiteknight: no. I'm happy with PIR. I wrote an entirely compiler in PIR.
whiteknight so that seems to be an argument for throwing the exception from the API *AND* the opcode
brrt its the fastest way to find it
Coke s/ly//
whiteknight: I don't think you have to be conflating those 2 things. 13:36
whiteknight Because most places that use the output of compreg don't check if it's null. They just pass it to the consumer and would get a null PMC exception instead of a more descriptive compiler-not-found one
moritz so how does one catch an exception from C land? 13:37
whiteknight moritz: depends, are we inside or outside libparrot?
moritz well, we're talking about the C API
so outside, I suppose
brrt hey, thats exactly how i eventually figured it out 13:38
whiteknight if we're outside libparrot in an embedding application, I think you can install a C function callback to try and handle it
brrt winxedst2.winxed asks for the PIR compiler
whiteknight unhandled exceptions are stored in the interp and cause that particular api to return 0
moritz so it's not actually an exception from C
brrt but its null (if imcc_get_pir_compreg_api was not called)
whiteknight when any API returns 0, you can call Parrot_api_get_results to get the exception, the error message, backtrace and exit code
moritz: oh no no no 13:39
brrt which gives you a super-helpful 'null pmc in find method' error :-p
moritz it's more like "pretending that compreg threw an exception"
brrt exactly
whiteknight C doesn't do exceptions, so when we cross that boundary we need to turn it into something C can consume
moritz which is why I've been confused by "throwing an exception from the C API"
whiteknight brrt: The find_method exceptions are known to be a particularly unhelpful case
moritz: Right, we throw the exception like normal, expecting there are no handlers to catch it, and let the normal error reporting mechanism handle the details 13:40
Coke ah. if the api functions are actually returning 0, then I have no argument.
whiteknight so C doesn't see the exception, it gets a flag to say that an Exception PMC is stored somewhere to be read and reported
Coke *facepalm*
whiteknight That's a facepalm? 13:41
moritz wonders if one can climb those palms :-) 13:42
Coke given that the argument was "throw an exception instead of returning null" and you actually mean the same thing by these two phrases, yes. ;)
whiteknight no no no 13:43
API routines all return a true/false. All of them. Always. Other values are returned through out parameters
so the API in question is int success = Parrot_api_get_compiler(interp, compiler_name, &compiler)
the problem brrt is having is that this API is returning "1", but compiler is PMCNULL 13:44
he wants it to return 0 instead, by throwing an exception
moritz no
he wants it to return 0
but that doesn't need to be by throwing an exception
whiteknight and that only happens when an unhandled exception is thrown
that's what that success value means.
brrt ah, whiteknight beat me to it 13:45
Coke not finding a compiler is not a successful value. it should return 0.
whiteknight that success value only means "this API call exited normally" versus "This API call had an unhandled exception". That's it
there are no other options
So the question is, do we want to throw an exception when we can't find the compiler of the given name? 13:46
Coke "throw an exception".
yes.
whiteknight That's what I'm leaning towards too
So then the question is, do we want the same behavior in the compreg_p_s opcode?
Coke I want it to return 0. If you have to create an exception for someone to poke into, sobeit.
whiteknight I suggest the answer there is also "yes" 13:47
but that represents a semantic change for many existing users who should be aware of it
brrt unless the change only happens within the Capi call, which relatively few people use 13:48
whiteknight right
(clearly few people use it, otherwise this issue would have been decided long ago)
brrt i'm not even going to argue that within the C API people should use it often 13:49
whiteknight Basically, do we throw the exception in Parrot_api_get_compiler or in Parrot_interp_get_compiler ? The later is the workhorse shared by the API and the opcode
Anybody here could put together the changeset in ~5 minutes
brrt its a designish question, really 13:50
whiteknight exactly, hence my wanting to hear from cotto
13:50 jashwanth joined
whiteknight brrt: If you want to make that change locally and create a pull request, you can start working as if Parrot_api_get_compiler does what you want 13:57
One way or another you're going to get that result, and it doesn't matter from your level where the exception is thrown 13:58
brrt yes, but ironically, I don't use that function anymore 13:59
whiteknight heh
Okay, I'll talk to cotto and throw it together tonight (unless somebody beats me to it)
brrt we'll see, hows the io cleanup thing going 14:00
whiteknight it's moving along. I am having troubles with seek/tell and buffering 14:01
and buffering with r/w handles
brrt yeah, that is probably tricky 14:02
whiteknight Reading the old code, it's a miracle that it ever worked and that nobody complained about it
brrt or 'any software project > 2 years'
whiteknight I had naive seek/tell working, but when you read ahead into the buffer, any seek operation has to also update or invalidate the buffer 14:03
brrt ... i might be naive here, but that depends, doesn't it?
whiteknight yeah, definitely
if you can seek within the buffer that's always preferred
brrt suppose I have a buffer of 1k, and i seek forward 512 bytes, then half my buffer is still good 14:04
whiteknight if you can't, you need to invalidate the buffer
Although some streams, like a read-only file probably won't change no matter what, so it's a shame to just dump that data
and eventually we're going to want a flag to transparently mmap the file, then buffering is completely unnecessary and we can seek with simple pointer arithmetic 14:05
brrt supposing your loginc
ah, enterfail
also, i'm not sure if you should do so much work to make io be nice to dumb programmers 14:06
moritz aren't all programmers dumb? :-) 14:07
brrt very much so, but only in different ways
anyway, seeking all over a file without mmaping it is not a clever strategy 14:08
whiteknight If I were implementing this from the ground-up, maybe we wouldn't have arbitrary seek on handles
but, we have an existing API to follow
And I've got to maintain the same old interfaces and the same lousy semantics, for now 14:09
The new architecture will allow us to do much smarter things in the future, but for right now I have to prove it works the same way, then start introducing new interfaces to do better things
brrt seek on a filehandle is fair enough, seek on a stringhandle easy to emulate, seek on anything else is dumb :-p
whiteknight right, and things get really stupid when you realize that Parrot abuses FileHandle to act as a pipe too, and seek on a FileHandle in pipe mode is bad 14:10
and seek on sockets are bad
brrt i can sort of see the pipes-are-files arguments
whiteknight right, but asking what file.exit_code() is doesn't
brrt lol 14:11
whiteknight And if we're doing something like file.open('foo.exe', 'rp'), that's just one pipe. What if we want 2-way or even 3-way pipes? Can't do it
JimmyZ new architecture? new IO architecture?
whiteknight JimmyZ: The whiteknight/io_cleanup1 branch
brrt hmm.... 14:12
whiteknight should really be renamed to whiteknight/io_omg_everything_is_changing1
JimmyZ yeah I know that branch
what's next stop? whiteknight/oo_cleanup1? :P
whiteknight next stop is whiteknight/6model
followed by whiteknight/alcohol 14:13
brrt followed by whiteknight/hangover
whiteknight right, I've got my whole summer planned out :)
brrt oh, you intend to do 6model this summer? :-p
Coke hopes that at some point, partcl will start working again. 14:15
Coke really hopes he doesn't have to give up on nqp and rewrite it a ... 4th? time.
PerlJam Coke: why would you give up on nqp? 14:16
JimmyZ rewrite it by rakudo :P
whiteknight brrt: benabik submitted two proposals for GSOC: One for 6model and one for PACT. Since we want both, I promised I would do whichever one of his proposals wasn't accepted 14:17
And he is doing PACT
Coke PerlJam: because I have a bug that's been open in the parrot queue for 18 months with no resolution.
whiteknight After 6model, I want to do some compiler work. I want to get Jaesop and Cardinal up and running. I might also want to play with partcl too 14:18
Coke whiteknight: it's ok. you don't have to give me pity namedrops. ;)
whiteknight I sincerely do want to work on it a little. I find the language interesting
plus, getting partcl running is a lot less work than writing a new compiler from scratch, and we need compilers to prove and test interop 14:19
my master plan is nothing if not over-ambitious
PerlJam whiteknight++ indeed :) 14:20
Coke PerlJam: github.com/parrot/parrot/issues/448
14:22 brambles joined
whiteknight blah, I really wonder what happened to that branch I was working on 14:24
NotFound whiteknight: winxed drivers assume compreg does not throw. 14:25
whiteknight NotFound: how much effort would that take to change? We wouldn't change anything so close to the release
oh wait, we're not close to the release at all. I'm confused
NotFound I can change it, but I don't see the rationale. Returning null is perfectly reasonable. 14:26
PerlJam whiteknight: you scared me for a second since I'm doing the rakudo release this month
Coke pokes at using the latest nqp again.
NotFound Question: tell me what comp object handles this language. Answer: none. Nothing exceptional on it. 14:27
whiteknight NotFound: okay, that makes sense. We'll update the API and not touch the compreg
NotFound: sure, but if you do something like compreg("foo").compile("...") you get a very unhelpful null pmc in find_method exception instead of a "compiler not found" exception 14:28
Come to think of it, that find_method exception is a source of many problems. Maybe I need to fix that
NotFound An exceptional answer will be, for example: "No sane programmaer will ever use such name for a language!!"
whiteknight root cause analysis for the win
heh
"winxed? Is that even a real word?"
NotFound whiteknight: that is the old generic problem that can be solved by a sort of "Failure" PMC 14:29
moritz no, don't go there
whiteknight oh no he di'nt 14:30
14:33 mmcleric left
NotFound Uhhh... If i remember well, the problem of find_method error not telling the method name was fixed some time ago. 14:34
moritz nqp: pir::null().foo() 14:36
p6eval nqp: OUTPUTĀ«error:imcc:syntax error, unexpected '\\n'ā¤ in file '(file unknown)' line 36ā¤error:imcc:syntax error, unexpected DOT ('.')ā¤ in file '(file unknown)' line 37ā¤ā¤Ā»
moritz nqp: pir::null__P().foo()
p6eval nqp: OUTPUTĀ«Null PMC access in find_method('foo')ā¤current instr.: '_block1000' pc 29 ((file unknown):161190909) (/tmp/kdEbFSAjnc:1)ā¤Ā»
NotFound Right 14:41
14:54 isBEKaml joined
isBEKaml ~.~ 14:55
whiteknight hello isBEKaml 14:59
15:00 PacoAir joined
isBEKaml whiteknight: how's things today? 15:02
whiteknight isBEKaml: things are mostly good. you? 15:16
isBEKaml whiteknight: not much. hot days, long days.
whiteknight isBEKaml: whereabouts do you live? 15:17
isBEKaml whiteknight: India, down south.
whiteknight oh right, I asked that before 15:20
I need to start taking notes
isBEKaml whiteknight: you take notes about people? /looks around/ 15:21
15:22 kjs joined
NotFound We need a graphic of number of parrot developers / time zone. 15:23
An it must be dynamic, taking different DST into account. 15:24
isBEKaml like on #haskell's wiki?
but that's not dynamic. 15:25
NotFound For extra bonus point, allow frequent travellers to record they current location.
And for the Oscar, feed it automatically from the GPS on his phone. 15:26
moritz Big Parrot is watching you? 15:27
brrt i have a famously inreliable gps, so i'm not worried 15:28
NotFound Ah, yes: all the project must run in parrot.
Now you have big project.
brrt oh, thats going to be easy once mod_parrot is done
NotFound brrt: the phone part is not easy in the current state of the art. 15:29
brrt fair enough
NotFound brrt: Have you seen my email? I wrote it using the gmail app on a tablet for the first time, so I'm not sure if it'll be legible, or even if it was sent. 15:32
Checked my Sent folder, loos like it was sent. 15:36
brrt yes, i have, did i respond? 15:46
probably not
NotFound brrt: just ask me any doubt.
brrt no, i didnt respond 15:49
nasty
yes, bytebuffer seems perfect for my needs
whiteknight: when shall we meet? 15:51
whiteknight brrt: now is fine. We don't need to talk about much
16:19 jashwanth joined 16:43 lucian_ joined
moritz "When shall we three meet again 17:02
In thunder, lightning, or in rain?"
17:27 PacoAir joined
dalek CT: 8814aba | benabik++ | / (2 files):
Initial build script
 17:33
18:04 PacoAir joined
dalek CT: c253a9c | benabik++ | setup.winxed:
Don't need OS
 18:09
CT: 406c421 | benabik++ | t/dummy.t:
Add a dummy test file
CT: 48dd52b | benabik++ | Makefile:
Add Makefile that forwards to setup.winxed

Borrowed from Rosella
whiteknight I really should add that to distutils, to automatically make a forwarding makefile 18:16
benabik whiteknight: Rosella is very useful. 18:17
whiteknight thanks! I try
benabik Although I was fairly surprised that distutils already has a useful test target... 18:18
whiteknight I didn't have a lot of success with using it, but I didn't play with it too hard 18:19
benabik Just putting in the test file and running `winxed setup.winxed test` worked for me. *shrug* 18:20
whiteknight oh yeah, it uses the built-in prove program
but I wanted it to use my custom harness, which is where I was having problems
18:24 lucian_ joined
whiteknight I can never just do things the easy way 18:24
benabik But that's why we like you. :-)
dalek kudo/nom: 559c402 | moritz++ | / (3 files):
typed NYI exception
 18:37
nxed/declare_auto: 4102182 | NotFound++ | winxedst2.winxed:
testing syntax
 18:43
nxed/declare_auto: 8fce893 | NotFound++ | winxedst2.winxed:
refactor DeclareItem: store the registar type, not the register name
nxed/declare_auto: 2a7f1bd | NotFound++ | winxedst2.winxed:
move var creation to optimize phase in the places that were doing it early
nxed/declare_auto: 7bab056 | NotFound++ | winxedst2.winxed:
Merge branch 'auto_declaration' into declare_auto
nxed/declare_auto: 955c8b5 | NotFound++ | winxedst2.winxed:
actually implement 'auto' statement
 18:44
p: 52736bc | jnthn++ | src/ops/nqp.ops:
Toss old, long-replaced NFA evaluation op now it's eliminated from the stage0.
 18:53
19:00 kurahaupo joined
cotto #ps in 15 19:15
Coke rurban++ # (work on TPF stuff via cpanel) 19:26
rurban got a good deal with them :) 19:28
19:28 preflex_ joined
Coke happy to get more eyeballs on parrot as your time permits. 19:29
tadzik cpanel++ rurban++
19:36 kurahaupo joined
dalek p: d06828e | jnthn++ | src/ops/nqp.ops:
The current fates implementation could sometimes push the same candidate twice. While this wouldn't result in an incorrect parse, it could mean extra wasted work if both had to be called and fail. This fixes it, and also starts tracking how many fate edges we crossed at a given position, to prepare to handle other sorting needs.
 19:40
p: 10994ce | jnthn++ | src/ops/nqp.ops:
Prevent trying to allocate zero bytes.
19:44 kjs joined 20:16 PacoAir joined
dalek rrot/notfound/declaration-after-statement: cc2af07 | NotFound++ | config/auto/warnings.pm:
drop -Werror=declaration-after-statement from auto config
 20:38
rrot/notfound/declaration-after-statement: e0095f4 | NotFound++ | src/string/api.c:
profit from declarations after statements:

make some of it const, now that we can
NotFound cotto: the branch you asked
cotto notfound++ 20:40
dalek : c1a5dc0 | kjs++ | src/ (8 files):
clean up code so that it (almost) compiles with g++.
 20:42
rrot/notfound/declaration-after-statement: e2f5606 | NotFound++ | config/auto/warnings.pm:
move some options from gcc-g++ to gcc only, to avoid noise with recent g++
 20:50
rrot/notfound/declaration-after-statement: ce35df3 | NotFound++ | src/pmc/fixedpmcarray.pmc:
use some declarations after statements in a pmc file
 21:14
NotFound That's all, ready for testing with msvc. 21:15
cotto did I mention NotFound++ 21:16
kjs hi cotto 21:18
NotFound When we get that branch merged, there will be a lot of job for cage cleaners. 21:19
cotto hio kjs 21:20
kjs hi there. quick question on M0 and function calls if you have time?
cotto I can try 21:21
kjs you know how in the poke_caller example, the name of the caller is stored in the chunk of the callee 21:22
as &caller
cotto yup
kjs is it possible to get to that name in the PFC?
cotto pfc? 21:23
kjs sorry, parent frame call
eh
PCF :-) sorry
cotto ah
kjs parent call frame
cotto do you mean the string name or the chunk number?
kjs not sure what i need for "goto_chunk" 21:24
cotto the chunk number is just an int const in the const table.
kjs the poke-caller example loads "&caller" into an I register, and passes it on to goto_chunk as first
cotto that's the first arg to goto_chunk, iirc
kjs arg
yes
that way, the callee chunk goes back
I'm storing a chunk's name always at index 0 of its own constants segment 21:25
so, i always can get to index 0 in a const segment to get that chunks name
cotto so you want to make sure that a function returns to the right place, no matter where it's called from?
kjs I want it to return to its caller
at the end of a chunk. 21:26
cotto I think that'd be PCF[CHUNK]
kjs so if you pass PCF[CHUNK] to goto_chunk, then that should be it?
(through a reg. of course)
ah. well that segfaults 21:27
21:28 bluescreen joined
dalek p/altnfa: 23b8c3e | moritz++ | tools/build/Makefile.in:
[build] include @optimize@ in CCFLAGS
 21:29
p/altnfa: 52736bc | jnthn++ | src/ops/nqp.ops:
Toss old, long-replaced NFA evaluation op now it's eliminated from the stage0.
p/altnfa: d06828e | jnthn++ | src/ops/nqp.ops:
The current fates implementation could sometimes push the same candidate twice. While this wouldn't result in an incorrect parse, it could mean extra wasted work if both had to be called and fail. This fixes it, and also starts tracking how many fate edges we crossed at a given position, to prepare to handle other sorting needs.
p/altnfa: 10994ce | jnthn++ | src/ops/nqp.ops:
Prevent trying to allocate zero bytes.
p/altnfa: b44ede4 | jnthn++ | src/ops/nqp.ops:
First crack at trying to consistently get declaration order tie-breaking correct.
p/altnfa: 59d4cb1 | jnthn++ | / (2 files):
Merge latest master into altnfa.
p/altnfa: bb9bb79 | jnthn++ | src/ops/nqp.ops:
If we see a fate a second time, and this offset gets multiple, make sure we include it into the sort.
p/altnfa: 0a0a2d0 | jnthn++ | src/how/NQPClassHOW.pm:
Retain order of method addition.
cotto make sure that PCF[CHUNK] is getting set correctly (or inspect the call frame to see if its value looks right) 21:31
rakudo projects get some of the most interesting commit messages 21:45
dalek : 1b7ea2a | kjs++ | src/gencode.c:
try to access parent's callframe's const segment, to find the caller's name. doesnt work though
 21:48
cotto that's the parent callframe's chunk's offset, not its name 21:56
might be misreading
kjs what i'm trying to do is, rather than getting *this* chunk's constant table, and finding the caller's name there, I'm trying to find it in the caller's const table (which is the parent cf) 21:57
the name is stored as &caller, &main, etc. 21:58
aloha, nopaste?
aloha kjs: nopaste is is nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl)
nopaste "kjs" at 89.101.178.50 pasted "generated code bare bones for a function call and return" (91 lines) at nopaste.snit.ch/143273 21:59
"kjs" at 89.101.178.50 pasted "generated code bare bones for a function call and return" (86 lines) at nopaste.snit.ch/143274 22:00
kjs sorry, first link i manually edited
second link is generated code. calling code is fine i think 22:01
cotto in the const table, &something is an int constant, not a string
kjs really? the assembler seems to handle it as a string
cotto let me verify
kjs and the interp in C looks for them by name, in goto_chunk op
line 359 in m0_assembler.pl 22:02
cotto ah
yes, but when the m0b is loaded it's turned into an int
kjs ok, but i'm doing essentially the same as poke_caller example 22:03
cotto that's because you can't know at assembly-time what a chunk's offset will be
kjs ... except looking in the current chunk's CONST table, i'm looking in PCF's const table.
cotto: I've also pointed this issue out in an email earlier today on the list. I need to go now, but perhaps once you have a bit of time you can look into this? 22:09
cotto sure
dalek kudo/map2: 9238ead | pmichaud++ | src/ (2 files):
Use nqp::istype and nqp::islist from NQP; update DUMP to recognize QRPA.
 22:10
22:11 not_gerd joined
not_gerd kjs: as I understand it, scan ops are out of scope of m0 22:12
in fact, arent the print ops supposed to go away as well?
kjs not_gerd: I would expect yes, 22:13
but until then... some input/output would be handy
until we can implement libraries.. (function calls! :-)
not_gerd what I'd like to see is something less heavy-weight than FFI for virtual/dynamic ops 22:15
ie a special m0 op which calls to functions with a fixed, yet to be determined signature 22:16
dalek nxed/declare_auto: 5c61ca3 | NotFound++ | winxedst2.winxed:
inline return type 'auto'
 22:17
cotto not_gerd, that would mean a lot of ops thouhg
*though
not_gerd cotto: just one additional op which takes a function pointer and a pointer to the arguments (or an offset into the registerset - depends on the calling convention we want to implement here) 22:19
kjs the args can be loaded into an array perhaps?
and a bunch of flags describing them 22:20
I've also thought about "lightweight" functions. essentially, all M1 code would go into 1 chunk and "functions" would just be chunk-internal labels 22:25
args passing through a "stack", which is just a blob of mem that is malloc'd 22:26
22:26 kjs left
not_gerd hm.. I don't think the 'linking stage' (translating chunk names into integer indices) is implemented yet--- 22:30
cotto It might not be in c-m0 22:34
istr p5-m0 doing it correctly
It looks like c-m0 doesn't do that. 22:36
not_gerd so if we want to mirror the perl-code, we'll need to add a hashtable implementation and put it into CHUNK_MAP 22:38
cotto so that's likely part of the problem
something like that, yes
there's no reason not to reuse the existing hash code from parrot though 22:39
(or the useful subset)
that's probably why it hasn't been implemented yet 22:40
not_gerd from reading the code, I'd say implementing a hashtable from scratch would be less effort than ripping out the Parrot-specific bits from the existing implementation... 22:48
22:53 whiteknight joined
whiteknight good evening, #parrot 22:55
not_gerd cotto: things I noticed while reading the C code: gist.github.com/2878662 22:58
cotto not_gerd, all good ideas 22:59
not_gerd if no one beats me to it, I might take a shot at that... 23:03
23:06 whiteknight joined
whiteknight re-good evening, #parrot 23:06
not_gerd re-good evening, whiteknight and good night #parrot 23:07
not_gerd is getting sleepy
23:07 not_gerd left
whiteknight my computer no longer works with my mouse 23:22
and my trackpad hasn't worked in months
which means I'm rocking the keyboard 100%
23:23 lucian_ joined 23:41 rurban_mobile joined 23:49 kurahaupo joined
dalek rrot: e4b931d | Whiteknight++ | src/embed/api.c:
Throw an exception from Parrot_api_get_compiler if the compiler cannot be found. brrt++ for the suggestion.
 23:54
23:58 nbrown joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!