Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
At 12:53 PM +1000 4/15/07, Jacinta Richardson wrote: Juerd wrote: Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? Yes, this needs to be redesigned completely. Are you volunteering? Is this still needed? If so yes, I'm now volunteering! Where'd you like me to start? All the best, Jacinta Pursuant to Juerd Waalboer's contributions to the relevant perl6-users discussion threads on 20060917,21, a replacement effort has been started. See the ext/HTTP/ and ext/Web/ skeleton code in the current Pugs repository, which is basically a copy of Juerd's code in the discussion emails, which I wrapped with distributions on his behalf on 20070217. Presumably Juerd will get back to these when he has the tuits, but meanwhile you could try improving what he started. -- Darren Duncan
Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
Darren Duncan skribis 2007-04-14 23:37 (-0700): Presumably Juerd will get back to these when he has the tuits, but meanwhile you could try improving what he started. Indeed. Please read these two posts to this list: http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=stq=juerd+web+developmentrnum=1#a209deddfadad19b http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/2e67c41cf3bd5e35/5db1c4513fb847ff?lnk=stq=juerd+web+developmentrnum=2#5db1c4513fb847ff They outline my thoughts; you'll probably be able to extrapolate most of the interface from it. Whenever you have specific questions, or get stuck, don't hesitate to ask. I can probably find a tuit or two to help, or someone else might. Thanks, -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
[perl #39063] [TODO] ResizableBooleanArray uses 64 bytes per bit of information
The current implementation of ResizableBooleanArray appears to use 64 bytes for each element. It would be nice to reduce that significantly. Either ResizableBooleanArray has been significantly refactored since this ticket was submitted last year (it has been), or the ticket was never true in the first place (possibly also true). In the current implementation of ResizableBooleanArray and FixedBooleanArray, each bit of information is stored as a single bit of an unsigned char (Parrot_UInt1).
Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
At 10:23 AM +0200 4/15/07, Juerd Waalboer wrote: Please read these two posts to this list: http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/845b10b8ed7266/a209deddfadad19b?lnk=stq=juerd+web+developmentrnum=1#a209deddfadad19b http://groups.google.nl/group/perl.perl6.users/browse_thread/thread/2e67c41cf3bd5e35/5db1c4513fb847ff?lnk=stq=juerd+web+developmentrnum=2#5db1c4513fb847ff They outline my thoughts; you'll probably be able to extrapolate most of the interface from it. I should also point out that copies those 2 list posts are also in the Pugs repository, in the docs/ folder of ext/HTTP/ (the more central of the 2 derived projects); I put them there at the same time as creating ext/HTTP/ for purposes of both explanation and posterity; the implementation and rationale are together. Eg, see: http://svn.pugscode.org/pugs/ext/HTTP/docs/ The main advantage to seeing the perl6-users archive versions is that list replies from other people can also be seen there. -- Darren Duncan
Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
Hi, Jacinta Richardson wrote: Juerd wrote: [CGI.pm et al] Yes, this needs to be redesigned completely. Are you volunteering? Is this still needed? If so yes, I'm now volunteering! Where'd you like me to start? I'd like to point out that this might be a good idea for a perl6 microgrant: http://use.perl.org/article.pl?sid=07/03/22/1542235 Afaict so far only 2 out of 10 are granted, so ideas and applications are welcome. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ - http://sudokugarden.de/ - http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: [perl #38887] Result of INFINITY or NAN stringification is platform dependent
On Sun, Jul 16, 2006 at 12:49:27PM +0100, Ron Blaschke wrote: On Win32 the implementation is simple because the IEEE recommended functions _finite and _isnan are supported. I'm thinking about adding a test for these functions and use them. But what should happen if they are not there? nan == nan isn't true, so that ought to be a portable test for a NaN (although Intel's compiler's default optimisation setting is buggy in this respect) I don't know of a good way to test for inf. Nicholas Clark
[perl #42536] build error on Linux 2.6.9-023stab041.3-smp
# New Ticket Created by Will Coleda # Please include the string: [perl #42536] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42536 Begin forwarded message: From: Andrew Shitov [EMAIL PROTECTED] Reply-To: Andrew Shitov [EMAIL PROTECTED] On behalf of the Parrot team, I'm proud to announce Parrot 0.4.10 The Release Formerly Known as Prince. I tried to compile source of 0.4.10 on Linux 2.6.9-023stab041.3-smp and got this error while 'make'ing the parrot: Invoking Parrot to generate runtime/parrot/include/config.fpmc -- cross your fingers ./miniparrot config_lib.pasm runtime/parrot/include/config.fpmc ./miniparrot: error while loading shared libraries: libicuuc.so.36: cannot open shared object file: No such file or directory Shared library is installed at /usr/local/lib/libicuuc.so.36. Could you tell me what to do and which way to see to solve the issue? Thank you. -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Executing Perl 6 code using PIR backend
Hi perlers, maybe I have missed something but I cannot run pugs with -C option. Initial goal was to compile Perl 6 programme into bytecode and run it (with parrot or even mod_parrot). First step is to convert the simpliest code test.p6 which contains say 'Hi!'; into .pir-file, so I typed pugs -CPIR test.p6 test.pir and really received test.pir file. What to do next? There are two ways in mind: either use pugs -B or parrot. When I call pugs with an option -B pugs -BPIR test.pir an error occured: *** Unexpected ' expecting comment, operator, statement modifier, ; or end of input at h.pir line 2, column 6 Looks like -BPIR is totally ignored. The same error you will get if simply run pugs test.pir. OK, trying to use parrot for executing PIR-code: parrot test.pir Plenty of errors this time: error:imcc:syntax error, unexpected DOT in file 'h.pir' line 7 error:imcc:syntax error, unexpected DOT in file 'h.pir' line 180 error:imcc:syntax error, unexpected DOT in file 'h.pir' line 194 . . . All these 'unexpected DOT' messages correspond to staments in PIR-source with 'new' instruction such as $P8 = new .PerlArray Would anyone tell me how to deal and live with it? :-) Pugs -v is 6.2.13 and parrot -V is 0.4.10 --without-icu on i386-linux. -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Re: Executing Perl 6 code using PIR backend
On Apr 15, 2007, at 11:36 AM, Andrew Shitov wrote: Hi perlers, SNIP of Pugs stuff OK, trying to use parrot for executing PIR-code: parrot test.pir Plenty of errors this time: error:imcc:syntax error, unexpected DOT in file 'h.pir' line 7 error:imcc:syntax error, unexpected DOT in file 'h.pir' line 180 error:imcc:syntax error, unexpected DOT in file 'h.pir' line 194 . . . All these 'unexpected DOT' messages correspond to staments in PIR- source with 'new' instruction such as $P8 = new .PerlArray Would anyone tell me how to deal and live with it? :-) All of the Perl* PMC types were changed into dynamically loaded PMCs - they're not available at runtime without jumping through some hoops. (These were designed for a more perl5-ian set of requirements, and weren't going to be used by the perl6-on-parrot effort.); Most of the Perl types have builtin parrot analogues, however: PerlArray - ResizablePMCArray PerlHash - Hash PerlString - String PerlInt - Integer PerlNum - Float PerlUndef - Undef PerlEnv - Env PerlScalar is kind of a base class for the string/int/num types, I'm not sure if there's a direct analogue in core parrot. The old perl PMC stuff is still in the parrot repository for the moment in languages/perl5/. Hope this helps, though I'm out of touch enough with Pugs that I don't know if this is related to something in pugs-land that needs updating. -- Will Coke Coleda [EMAIL PROTECTED]
Re: Should a dirhandle be a filehandle-like iterator?
On Fri, Apr 13, 2007 at 08:14:42PM -0700, Geoffrey Broadwell wrote: [...] -- so non-dwimmy open variants are a good idea to keep around. This could be as simple as 'open(:!dwim)' I guess, or whatever the negated boolean adverb syntax is these days open(:file), open(:dir), open(:url), ... could be the non-dwimmy versions. If you don't specify an explicit non-dwimmy base variant, the dwim magic makes a (preferrably appropriate) choice. --
[perl #42533] [TODO] do not check PIR coda for languages/dotnet/src/builtins.pir
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #42533] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42533 languages/dotnet/src/builtins.pir is a generated file, so editor hints are not very useful there. So t/codingstd/pir_code_coda.t should not check builtins.pir. If that is hard, then languages/dotnet/build/builtins.pl could be taught to emit the unneeded PIR coda. Regards, Bernhard
Re: Should a dirhandle be a filehandle-like iterator?
On Sun, Apr 15, 2007 at 01:16:32PM -0400, John Macdonald wrote:
: On Fri, Apr 13, 2007 at 08:14:42PM -0700, Geoffrey Broadwell wrote:
: [...] -- so non-dwimmy open
: variants are a good idea to keep around.
:
: This could be as simple as 'open(:!dwim)' I guess, or whatever the
: negated boolean adverb syntax is these days
:
: open(:file), open(:dir), open(:url), ... could be the non-dwimmy
: versions. If you don't specify an explicit non-dwimmy base
: variant, the dwim magic makes a (preferrably appropriate) choice.
I suspect that since we have a type system now we should probably use it
for the non-dwimmy versions.
my $io = IO::File.open($str)
my $io = IO::Pipe.open($str)
my $io = IO::Socket.open($str)
my $io = IO::Dir.open($str)
my $io = IO::URI.open($str)
etc. And of course different kinds of objects can have different
defaults. I'd guess the default for directories is to take a snapshot
and sort the entries, for instance. Certainly the open is the only
place we have to distinguish the type, and $io.close will close
any of them.
To me the interesting question is, when do we assume that a string
is a filename or uri? I can argue that for historical and security
reasons bare open() should always assume the provided string is a
normal filename. However, given that the existence of feed operators
removes most of my objections to Ingy's io() interface, we could make
that default to uri processing:
io('http://www.wall.org/~larry') == my @homepage;
Though we have a bit of a semantic problem insofar as
@source == io('file:foo')
is going to want to supply more arguments to io() rather than send
the feed to some method of the IO object, unless io() is some kind of
a context-sensitive macro, or at least has a signature that doesn't
allow slurpies. And currently feed ops are considered statement
terminators, which makes it odd to think about overloading them.
More of a problem is that multiple dispatch based on argument type
depends on eager evaluation of dynamic types, while feeds are basically
lazy. We don't know how hard to call io() without recognizing it
as special, or specifying the actual method:
@source == io('file:foo').print
Maybe that's good enough, but it seems like we could do a little
better. Hmm, type coercions tend to be unary, or at least not
listy, so maybe we can just recognize types as returning source
and sink objects, which feeds automatically call with an appropriate
variadic method (.lines, .print, .tap) depending on pointiness:
IO('http://www.wall.org/~larry') == my @homepage; # implicit .lines
@source == IO('file:foo') # implicit .print
@source == IO($debuglog) == @sink # implicit .tap
Larry
PDD15 implementation status
Hi, With much of PDD15 implemented, I thought it'd be good to explain how far along we are (and aren't) as the next release approaches. Here's some code examples. --- # You can initialize a class with a hash... $P0 = new 'Hash' # Set name Will also associate with Monkey namespace nested in current NS. # You can set $P0['namespace'] instead (or as well) to specify a full keyed # namespace, which is taken to be from the HLL root. $P0['name'] = 'Monkey' # Make an array of attributes. $P1 = new 'ResizableStringArray' $P1[0] = 'banana' $P0['attributes'] = $P1 # Let's create a class! $P1 = new 'Class', $P0 # You can add stuff to it later too, provided it ain't instantiated yet. $P2 = find_global 'say_ook' add_method $P1, 'say_ook', $P2 # Add parents... $P2 = get_class 'Primate' add_parent $P1, $P2 # Create a role... $P0 = new 'Hash' $P0['name'] = 'JungleActivities' $P2 = new 'Role', $P0 $P3 = find_global 'ja_swing' add_method $P2, 'swing', $P3 # And compose it in! If we wanted to resolve conflicts, can use 'add_role' method. add_role $P1, $P2 # Instantiate it. $P2 = $P2.new() # Call methods and get/set attributes just as before. $P2.swing() $P3 = new 'Banana' setattribute $P2, 'banana', $P3 $P2.say_ook() # Inspect a class to find out about its guts. $P3 = inspect $P1 $P4 = inspect $P1, 'attributes' # Here's now to instantiate a class associated with a given namespace... $P5 = get_class [ 'Creation', 'Animals', 'Monkey' ] $P6 = $P5.new() --- Excuse any typo's in the above. As you can see, fairly capable. However, there's still some work to do and limitations. * addattribute segfaults if passed a PDD15 class. I'll fix that tomorrow, if nobody beats me to it * Oh, and the Role PMC doesn't do the name/namespace stuff right yet; it's mostly a case of looking at the Class PMC and stealing stuff. Doable before release...again, please beat me to it. ;-) * The Object PMC is missing some vtable methods and its guts need sorting out - also probably doable before release - I'll have time for this pre-release too * You can't inherit from a PMC yet. Depends on needed stuff being spec'd and implemented. * Overriding of vtable methods ain't implemented yet * Attribute composition from roles ain't implemented yet So I think we're looking at having PDD15 usable by some people in this release, but not being able to inherit from PMCs is going to prevent a lot of people jumping over to it just yet. It'll probably be a little while before we can really deprecate ParrotClass and ParrotObject. What we certainly need is more test coverage and feedback from people using the new stuff. I'm aware that I probably have the most in-depth knowledge of the PDD15 implementation. Parrot's losing me for pretty much all of May, so if anyone has questions on the code, please try and catch me about them within the next week, either on list or IRC. Have fun, Jonathan
Re: PDD15 implementation status
Jonathan Worthington wrote: #Instantiate it. $P2 = $P2.new() Uh... $P2 = $P1.new() D'oh. Jonathan
Re: PDD15 implementation status
On Sunday 15 April 2007 15:28, Jonathan Worthington wrote: * addattribute segfaults if passed a PDD15 class. I'll fix that tomorrow, if nobody beats me to it If there's a test case, I can probably fix it. That'll free you up to implement new things. -- c
Re: PDD15 implementation status
chromatic wrote: On Sunday 15 April 2007 15:28, Jonathan Worthington wrote: * addattribute segfaults if passed a PDD15 class. I'll fix that tomorrow, if nobody beats me to it If there's a test case, I can probably fix it. That'll free you up to implement new things. Sorry, I didn't get to adding one yet, but this should do it: $P0 = new 'Class' addattribute $P0 'foo' Thanks, Jonathan
Re: PDD15 implementation status
On Sunday 15 April 2007 15:52, Jonathan Worthington wrote: chromatic wrote: Sorry, I didn't get to adding one yet, but this should do it: $P0 = new 'Class' addattribute $P0 'foo' Hm, it segfaults for me (and rightly so) if I instantiate a non-class (try 'Hash' for some fun), but when I use this code (with the missing comma), I get: $ parrot -t class_crash.pir 0 new P0, Class P0=PMCNULL 3 addattribute P0, foo P0=Class=PMC(0x820f530) Null PMC access in get_string() current instr.: 'main' pc 3 (class_crash.pir:3) -- c
Re: [perl #42430] [PATCH] make :vtable imply :method
Here's the original post where I gave the rationale for making the flags
work as they do:
http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/5bbf1eab0133d467?tvc=2
I'm comfortable with a modification saying that :vtable always gets the
'self' parameter like :method does. But without :method, :vtable should
not make an entry in the namespace of the class, or call 'add_method' on
the class. This results in simpler syntax for the cases where you only
want to override the vtable entry.
# method name is the same as vtable name
.sub get_string :method :vtable
# accessible as either $obj.stringify() or vtable
.sub stringify :method :vtable('get_string')
# accessible only as vtable
.sub get_string :vtable
# accessible only as vtable, and sub name ignored
.sub stringify :vtable('get_string')
Allison
