Re: NCI and callback functions
Stephane Peiry <[EMAIL PROTECTED]> wrote: > ow.. ok, this one is actaully a macro.. the actual function is > gulong g_signal_connect_object (gpointer instance, > const gchar *detailed_signal, > GCallback c_handler, > gpointer gobject, > GConnectFlags connect_flags); > so I've changed this and now it does find it. Ah. Ok. You've mixed up the function parameters. > P0 = global "Gtk::gtk_window_new" > null I5 > invoke > P15 = P5 I presume that's "instance" ... > # -- function sig is "'lptpPi', then we have: > #P5 is the button > #P6 the callback > #P7 data we may to pass through. > #S5 "clicked" > #I5 is 0 ... and the button is the "gobject". I did: set P6, P5 # the callback set P5, P15 # instance set S5, "clicked" set P7, P11 # button = object And got a clickable button labeled "Parrot". You might start using PIR code and named variables so that it gets simpler to call such functions. leo
Re: [perl #31138] [TODO] Configure - dependencies fix
Matt Fowles <[EMAIL PROTECTED]> wrote: > All~ > I was thinking about reworking the Parrot build system to use scons > (http://www.scons.org/). The up side to this is that it would allow > more precise dependecies and could probably be used to eliminate the > configure step. The down side is that it introduces another > dependency. Rather not. Python is AFAIK not as portable as Perl. But there is a Perl based make somewhere, the named just escaped my mind. Further the build system per se isn't the real problem, the configure part needs much more tests. leo
Re: [PATCH] Match PMC
Steve Fink <[EMAIL PROTECTED]> wrote:
> I needed to create a Match PMC object for holding the match groups
> (parenthesized expressions and capturing rules) from a regex match.
> Unfortunately, it works by using another new PMC type, the MatchRange
> PMC,
> .. One PMC knowing about
> another currently means they need to be static PMCs, not dynamic.
> (AFAIK)
Dunno, if that is already solved. Mattia?
> +classes/matchrange.pmc - MatchRange Numbers PMC Class
> +#define RANGE_START(pmc) UVal_int((pmc)->obj.u)
> +#define RANGE_END(pmc) UVal_int2((pmc)->obj.u)
Please don't. PMC_int_val(pmc) and PMC_int_val2(pmc) are working.
> +void init () {
> +PObj_active_destroy_SET(SELF);
^^^
What shall be destroyed here?
leo
Re: [perl #31138] [TODO] Configure - dependencies fix
On Wed, Aug 18, 2004 at 09:21:22AM +0200, Leopold Toetsch said: > Rather not. Python is AFAIK not as portable as Perl. But there is a Perl > based make somewhere, the named just escaped my mind. It's called Cons. I can't remember whether Cons or Scons came first (ah, Cons was the orginal http://www.scons.org/faq.html#SS_6_2) http://www.dsmit.com/cons/ Requires Perl 5.003 or better and Digest::MD5
Re: [perl #31138] [TODO] Configure - dependencies fix
Simon Wistow wrote: Leopold Toetsch said: Rather not. Python is AFAIK not as portable as Perl. But there is a Perl based make somewhere, the named just escaped my mind. It's called Cons. I can't remember whether Cons or Scons came first (ah, Cons was the orginal http://www.scons.org/faq.html#SS_6_2) http://www.dsmit.com/cons/ Requires Perl 5.003 or better and Digest::MD5 There is a FAQ at http://www.baldmt.com/cons-faq/current.html
Re: Another small C task
At 12:40 PM -0400 8/16/04, Dan Sugalski wrote: I should [TODO] this, but I think it might get lost in the recent blast 'o TODO items. (All of which I'd be thrilled if someone took on. A big thanks to Will for diving into the queue and website and getting things in a semblance of order) This one's pretty simple. The functions we expose to embedders don't set the stacktop pointer, which causes Much Difficulty to folks embedding parrot as it'll segfault or lose track of PMCs. This is... bad. As you might expect. What needs to be done is pretty simple. There's code in src/embed.c in Parrot_runcode to set the lo_var_ptr value if it's NULL. (Code which needs a bit of refactoring now that I look at it) What we need to do is wrap the same "check if lo_var_ptr is NULL and temporarily set it to a spot in the current stack frame" code around any and all functions in extend.c which can call into the interpreter. Ah, ya bunch of slackers! :) Since nobody got to this, I went and did it. We now should properly protect the interpreter when calling into extension code from outside of an interpreter. This should, hopefully, make Ponie much happier. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Popping an empty stack
At 5:53 PM -0700 8/17/04, Brent 'Dax' Royal-Gordon wrote: Michel Pelletier <[EMAIL PROTECTED]> wrote: if Perl or other languages want an undef returned, it would seem to make more sense that they assume to cost of catching the exception and turning it into an undef, than everyone else turning the undef into an exception. I believe that this is exactly the sort of language-specific behavior that PMCs were designed to solve. Yup. But in this case the bounds checking is needed if you care, since: $bar = pop @foo; should return undef if @foo is empty. Call it a thousand times and you should cheerfully get a thousand undefs. If code wants to see if there's actually anything in @foo, then it has to check. (In the perl 5 case, of course) That should happen regardless of the language popping an element off of @foo. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Something to ponder
At 6:20 PM -0400 8/17/04, Aaron Sherman wrote:
On Tue, 2004-08-17 at 16:22, Felix Gallo wrote:
On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote:
> 1) We're going to have MMD for functions soon
> 2) Function invocation and return continuation invocation's
> essentially identical
> 3) Therefore returning from a sub/method can do MMD return based on
> the return values
$x -\
\
@mylist -+--- $obj.mymmdsub;
/
%hash --/
How very fungible of you ;-)
Still, I think that's a nice APPLICATION, but the concept is more
flexible, if I understand it correctly. It would be something that would
look more like a cross between exception handling and a switch
statement.
[snip]
Is that the kind of thing you had in mind, Dan, or am I misunderstanding
how return continuations work?
Yep, though the error dispatch case is definitely the easy one. Where
it gets fun is:
sub foo :come_from('bar', int) {
print "In foo!";
}
sub baz :come_from('bar', string) {
print "in Baz!";
}
sub bar {
return(rand() > .5 ? 1 : "Nope");
}
with that code, half the time it'll print "In foo!", the other half
"in Baz" when you call bar, because where it goes when bar exits
depends on what bar returns...
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Functions for embedders to override
On Wed, Aug 11, 2004 at 01:10:42AM -0400, Dan Sugalski wrote: > > >A good place to look at for the complete list is Perl 5's system > >abstraction layer. > > Yeah. If you've got time to get a list I'd very much appreciate it. http://search.cpan.org/src/NWCLARK/perl-5.8.5/iperlsys.h Tim.
Re: [perl #31138] [TODO] Configure - dependencies fix
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Rather not. Python is AFAIK not as portable as Perl. But there is a Perl > based make somewhere, the named just escaped my mind. We use Makepp (http://makepp.sourceforge.net/) here. Written in Perl, its particular strength is how it avoids recursive make (and thus lets us get the dependencies right). Dave. -- Verification Architect, NVIDIA.
Re: Something to ponder
On Wed, 2004-08-18 at 10:06, Dan Sugalski wrote:
> Yep, though the error dispatch case is definitely the easy one. Where
> it gets fun is:
>
> sub foo :come_from('bar', int) {
You've created an MMD come-from
Uh... that hurts.
I think using it for type-based, switch-like dispatch would be as far as
I'd be willing to use it. Beyond that it just starts to turn into spooky
action-at-a-distance.
--
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs
Re: Something to ponder
At 11:33 AM -0400 8/18/04, Aaron Sherman wrote:
On Wed, 2004-08-18 at 10:06, Dan Sugalski wrote:
Yep, though the error dispatch case is definitely the easy one. Where
it gets fun is:
sub foo :come_from('bar', int) {
You've created an MMD come-from
Uh... that hurts.
Yes, but imagine the possibilities! Especially when you consider that
all the basic operators are really doing function calls, so doing
basic math could redispatch somewhere else.
sub foo :come_from('+', int, int) {}
for example. Action at a distance has *nothing* on that...
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Something to ponder
Dan writes:
> sub foo :come_from('+', int, int) {}
One problem with MMD in general, and return specifically, is
'what happens if multiple M match the same D requirements?
i.e.,
sub foo :come_from('+', int, int) { shift; shift builtin::+ shift };
sub bar :come_from('+', int, int) { shift; shift builtin::* shift };
If the answer is 'all get executed', this could be useful for
any languages interested in implementing aspect-oriented programming
as a first class language feature, e.g.
sub debug_log :come_from(:benchmark_me) {
my $function_name = shift;
print STDERR "debug: $function_name at " . time() . "\n";
}
sub notify_with_pager :come_from(:notify_me) {
...
}
sub foo :benchmark_me { ... } # gets benchmarked
sub bar :benchmark_me :notify_with_pager { ... } # benched and notified
sub baz { ... } # not so much with the benchmarking
If the answer is 'the second match is a syntax error'...well,
that spoils the fun, but who said talking about continuations was
supposed to be fun?
F.
Re: NCI and callback functions
On Wed, Aug 18, 2004 at 09:11:17AM +0200, Leopold Toetsch wrote:
> You've mixed up the function parameters.
>
> > P0 = global "Gtk::gtk_window_new"
> > null I5
> > invoke
>
> > P15 = P5
>
> I presume that's "instance" ...
actually shouldnt the callback is for the button
> > # -- function sig is "'lptpPi', then we have:
> > #P5 is the button
> > #P6 the callback
> > #P7 data we may to pass through.
> > #S5 "clicked"
> > #I5 is 0
>
> ... and the button is the "gobject". I did:
>
> set P6, P5# the callback
> set P5, P15 # instance
> set S5, "clicked"
> set P7, P11 # button = object
>
> And got a clickable button labeled "Parrot".
do you mean the callback worked? as I dont get it to on my system
(ie if I activate the callback the it seg faults).
> You might start using PIR code and named variables so that it gets
> simpler to call such functions.
Ok I have changed this a bit and should be more readable.
Mainly attached is the C version of this small example, and the parrot
version is just about a conversion to it line be line.
(its simply a slightly modified of the Gtk tutorial "hello world",
where instead of using the #defined g_signal_connect it uses the
g_signal_connect_object function)
Unless Im overlooking something the parrot version mimics exactly
whats the C version does. Just still cant get it to work out the
callback.
> leo
Thanks always,
Stephane
/*
* Compile this with:
*
* gcc hello.c -o hello `pkg-config --cflags --libs gtk+-2.0`
*/
#include
static void hello( GtkWidget *widget,
gpointer data )
{
g_print ("Hello\n");
}
int main( int argc,
char *argv[] )
{
GtkWidget *window;
GtkWidget *button;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
button = gtk_button_new_with_label ("Parrot");
g_signal_connect_object (G_OBJECT (button), "clicked",
G_CALLBACK (hello), NULL, 0);
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
gtk_main ();
return 0;
}
# -- Gtk Button Example.
.sub _gtkcallback
print "Hello\n"
.end
.sub _main @MAIN
.include "gtk.pasm"
.local pmc window
.local pmc button
.local pmc callback
.local pmc userdata
P0 = global "Gtk::gtk_init"
I5 = 0
invoke
# -- create the window
P0 = global "Gtk::gtk_window_new"
null I5
invoke
window = P5
# -- create the button
P0 = global "Gtk::gtk_button_new_with_label"
S5 = "Parrot"
invoke
button = P5
# -- install callback?
newsub P6, .Sub, _gtkcallback
new P7, .Integer # -- just give it something even if dont care
set P7, 42
userdata = P7
new_callback P5, P6, P7, "Ut"
callback = P5
# -- function sig is "'lptpPi', then we have:
#P5 is the button
#P6 the callback
#P7 data we may to pass through.
#S5 "clicked"
#I5 is 0
# -- Uncomment this section to actually install the callback
# -- (this segfaulst on my system)
# P0 = global "Gtk::g_signal_connect_object"
# P5 = button
# S5 = "clicked"
# P6 = callback
# P7 = userdata
# I5 = 0
# invoke
# -- .
# -- Set the container.
P5 = window
P6 = button
P0 = global "Gtk::gtk_container_add"
invoke
# -- show button
P5 = button
P0 = global "Gtk::gtk_widget_show"
invoke
# -- show window
P5 = window
P0 = global "Gtk::gtk_widget_show"
invoke
P0 = global "Gtk::gtk_main"
invoke
end
.end
saveall
loadlib P1, 'libgtk-x11-2.0'
dlfunc P2, P1, 'gtk_init', 'vii'
store_global 'Gtk::gtk_init', P2
dlfunc P2, P1, 'gtk_main', 'vv'
store_global 'Gtk::gtk_main', P2
dlfunc P2, P1, 'gtk_widget_show', 'vp'
store_global 'Gtk::gtk_widget_show', P2
dlfunc P2, P1, 'gtk_container_add', 'vpp'
store_global 'Gtk::gtk_container_add', P2
dlfunc P2, P1, 'gtk_button_new_with_label', 'pt'
store_global 'Gtk::gtk_button_new_with_label', P2
dlfunc P2, P1, 'gtk_window_new', 'pi'
store_global 'Gtk::gtk_window_new', P2
dlfunc P2, P1, 'g_signal_connect_object', 'lptpPi'
store_global 'Gtk::g_signal_connect_object', P2
restoreall
Re: Something to ponder
On Wed, 2004-08-18 at 15:57, Felix Gallo wrote:
> Dan writes:
> > sub foo :come_from('+', int, int) {}
>
> One problem with MMD in general, and return specifically, is
> 'what happens if multiple M match the same D requirements?
> i.e.,
That's a question, not a problem. It's easy to answer questions ;-) I
assume we're talking about first-to-match only, but I haven't looked at
the code. You could always go look at the MMD code in the Parrot
source...
However, I'm not sure what Dan meant there. Perhaps he mis-spoke, or
perhaps I don't understand this at all... that's a calling signature,
not a return signature. I would expect:
sub foo :come_from('+', int) {...} # Handle integer returns
sub foo :come_from('+', num) {...} # Handle floating point
That's very different from a come_from that would operate on the calling
signature (which needs return continuations too, but differently).
Or did we just switch to talking about something different while I
wasn't looking?
> If the answer is 'all get executed', this could be useful for
> any languages interested in implementing aspect-oriented programming
> as a first class language feature, e.g.
You can build one from the other trivially, though and that doesn't
affect, in the slightest, how "first class" the feature is in a language
that uses Parrot, only how interchangeable it is between languages.
That, of course, dodges the question of how much aspect oriented
programming is an attempt to being the beauty of Intercal to ugly,
"usable" programming languages
> sub debug_log :come_from(:benchmark_me) {
> my $function_name = shift;
> print STDERR "debug: $function_name at " . time() . "\n";
> }
Ok, this is starting to look like people speaking seriously about using
Intercal's COME FROM (http://c2.com/cgi/wiki?ComeFrom)... can we just
step back and take a deep breath of AIR please? Seriously, this is
starting to creep me out.
--
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs
Re: Something to ponder
Aaron writes:
> Ok, this is starting to look like people speaking seriously about using
> Intercal's COME FROM (http://c2.com/cgi/wiki?ComeFrom)... can we just
> step back and take a deep breath of AIR please? Seriously, this is
> starting to creep me out.
In case anyone reading this is getting confused, here are
some other interesting links:
Aspect Oriented Programming primer: ('come from' for Java)
http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html
The original intercal specification (a must read; this is
the version without the taint of esr):
http://www.muppetlabs.com/~breadbox/intercal/intercal.txt
I don't know why Aspect Oriented Programming would creep you out.
It seems to have a moderately devout following amongst a certain
sect of Java programmers, and certainly there are places where
it's clearly a ... well, I won't say a good idea, but at least
a comprehensible one. Being able to implement AspectJ 'natively'
rather than via a set of C++-like preprocessor hacks is not
necessarily a bad thing. Even the fact that esr already did it
in a joke language is neither here nor there.
Anyway, Parrot could never implement COME FROM for real, because
it doesn't support the notion of STEP:
20 COME FROM 70 STEP 20
Felix
[perl #31229] [PATCH] Missed pod nit in build_tools/c2str.pl
# New Ticket Created by Will Coleda # Please include the string: [perl #31229] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31229 > Index: build_tools/c2str.pl === RCS file: /cvs/public/parrot/build_tools/c2str.pl,v retrieving revision 1.5 diff -b -u -r1.5 c2str.pl --- build_tools/c2str.pl20 Apr 2004 19:21:33 - 1.5 +++ build_tools/c2str.pl18 Aug 2004 23:15:16 - @@ -151,6 +151,7 @@ } =pod + print <<"HEADER"; /* * !!! DO NOT EDIT THIS FILE !!!
Re: Something to ponder
At 3:57 PM -0400 8/18/04, Felix Gallo wrote:
Dan writes:
sub foo :come_from('+', int, int) {}
One problem with MMD in general, and return specifically, is
'what happens if multiple M match the same D requirements?
Well... usually what happens is that an ambiguous function error is
thrown. I can see getting quantum and going for all of them at once,
though. That'd be really cool...
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Something to ponder
Felix Gallo wrote:
Aaron writes:
Ok, this is starting to look like people speaking seriously about using
Intercal's COME FROM (http://c2.com/cgi/wiki?ComeFrom)... can we just
step back and take a deep breath of AIR please? Seriously, this is
starting to creep me out.
Aspect Oriented Programming primer: ('come from' for Java)
http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html
Actually, I was just talking about the COME FROM bits, not the AOP bits.
I happen to think that AOP is nearly impossible to implement in a way
that is maintainable, but if someone proves me wrong, then there it is.
It's spooky action at a distance, but it at least has some structure,
and you know why and when to expect it.
COME FROM is very different, and (as with much of Intercal) was created
specifically to be obtuse. Discussing it as if it's a useful feature
tends to creep me out because I get the feeling someone might actually
put it in a language I care about.
Re: Something to ponder
Aaron writes: > COME FROM is very different, and (as with much of Intercal) was created > specifically to be obtuse. Discussing it as if it's a useful feature > tends to creep me out because I get the feeling someone might actually > put it in a language I care about. I feel the same way about gethostent, picture formats and blockless 'package'. And AOP, Swing and ATL, for that matter. Que sera etc. Felix
