Re: cperl-mode.el: twigils and opers
Steffen Schwigon [EMAIL PROTECTED] writes: I checked and indeed the twigils don't work. My test source file (which worked correctly some time ago) also highlights wrong. It's for sure a bug I introduced. I now did some things on cperl-mode (eg. syncing with original v5.20) and it seems highlighting of twigils generally works again. Please try again, but in the meantime with longer variable names, because ... I can't promise that it also worked with y as variable name. That's probably a second issue. That's indeed a different issue. Using short variable names y,tr,s,m,... with twigils still irritates it. Not yet solved. Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: synopses on smoke server
On 9/5/06, Christopher D. Malon [EMAIL PROTECTED] wrote: In summary, the basic pattern would be: (a) smokeserv-client sends both .html and .yml of smoke I really really want this feature. I've even added this to Pugs' TASKS file. (b) If smokeserv-server gets .yml, it checks out the t/ directory for that revision, and To be honest, at this moment I don't quite care about checking out t/. Instead I just hope the new smoke server can make the tests.yml with largest rev number available somewhere in the index page. ;-) (c) smokeserv-server runs smartlinks.pl on the .yml with that t/ directory and indexes it. I don't know if the smoke server has checked out smartlinks.pl like feather. My current plan is to run smartlinks.pl on feather and render the synopses using the latest version of pugs smoke results. I admit your approach is much saner, but apparently needs much more work. :) I also share a lot of your questions. Hopefully the maintainer of the current smoke server (ingy or nothingmuch?) can give some guide here. :) Cheers, Agent
Re: synopses on smoke server
Hi, Christopher D. Malon wrote: Agentz++ writes, in a Pugs blog comment: if someone can offer regular smoke results (i.e. the tests.yml generated by `make smoke'), we can render the Synopses on feather with smoke results as well The obvious way to get this to happen, for all runtimes, is to integrate the synopsis-with-smoke production with the existing smoke server infrastructure. I've started hacking this in, but have some concerns. A few are mainly directed to iblech++. 1. Multi-versioning the tests: The inlined tests need to match the revision at which the smoke was produced. Is it okay to have the smoke server check out the relevant revision of the pugs/t directory each time a smoke of a new revision is submitted, or is that too expensive? Currently, the smokeserver does not run smartlinks.pl etc., but redirects to tests.pugscode.org via .htaccess: Redirect /iblech/stuff/pugs-smokes/t http://tests.pugscode.org/t Redirect /iblech/stuff/pugs-smokes/ext http://tests.pugscode.org/ext (tests.pugscode.org used to be an alias to something under http://feather.perl6.nl/.) This way the smokeserver doesn't need to do anything except storing the .html of smokes; especially it doesn't have to be updated WRT new synopses/tests/smartlinks.pl. Accordingly, ... 3. What is the full path to smartlinks.pl on the smoke server? ...there is none. 5. Will a commit that changes smokeserv-server.pl be picked up by the smoke server right away? No; currently, you'll have to ping me (best by mail). (Note that testing the smokeserver locally shouldn't be hard, as it doesn't require setting up a proper database etc. Copying smokeserv-serv.pl somewhere under cgi-bin/ and adjusting the paths should suffice.) I might down the whole smoke system with my commit. Anyone willing to debug with me when I do? I am, of course. :) --Ingo
select / PIO_unix_poll / IO event
Hi, I'm currently hacking httpd.pir a bit and came along the need for a select/poll system interface (httpd.pir fails e.g. with konquerer, for multiple connections). We currently have: 1) PIO_unix_poll It can select just on one fd, which isn't helpful at all (despite the comment in the src code). Also the name is misleading, as it's implement using select(2). If we take 1), then the interface needs to be redone to take 3 arrays of PIO PMCs or such. Passing in Boolean aka Bit arrays as fd_set might be unportable. 2) The event system It's not toatally ready to use it for waiting on file descriptors, but most is already there. A minimal interface could be: event_add_IO_event(Interp, PMC* pio, PMC *sub, PMC *user_data, int which) event_del_IO_event(Interp, PMC* pio, int which) where which is _READ, _WRITE, or _ERR If select returns with one of these pio fds, it would schedule an interpreter IO event, which eventually runs the the user handler subroutine with: .sub io_handler # the sub above .param pmc pio# it got ready .param pmc user_data Solution 2) would be fully asynchronous. Comments welcome, leo
(Non)shared interpreter data
Hi,
with the arrival of STM and (again) thread support in parrot trunk, we should
ponder various interpreter structures and data regarding their usage with
threads.
E.g. classes, namespaces, bytecode, IO PMCs, and likely more.
Here are my thoughts so far:
1) classes / PMC types
As any thread could create new types on the fly (even in an eval-like manner),
it seems to me, that Cinterpreter-class_hash is distinct per thread. Some
lazy copy feature of already existing classes would probably be desirable.
2) namespaces
Ditto, the more that there are some rumours that class isa namespace.
3) bytecode / subroutines
These shall be shared. *But* there's the problem of per-thread data in
bytecode-related structures. E.g. the PIC structure or
PMC_sub-namespace_hash are per thread, which currently causes some excessive
cloning of subroutines. There's of course also a problem, if a thread does
Cload_bytecode or eval.
4) IO
When I'm reading POSIX specs or manpages correctly, then file descriptors are
shared amongst threads. The implementation is then currently wrong as
Cinterpreter-piodata is allocated per interpreter/thread.
Regarding per-thread data in shared structures: a per interpreter array
(indexed by a public key, which is stored in the shared structure) would
help. See also pthread_{s,g}etspecific(3p) and pthread_key_create(3p).
Comments welcome,
leo
Re: synopses on smoke server
Hi, Currently, the smokeserver does not run smartlinks.pl etc., but redirects to tests.pugscode.org via .htaccess: Redirect /iblech/stuff/pugs-smokes/t http://tests.pugscode.org/t Redirect /iblech/stuff/pugs-smokes/ext http://tests.pugscode.org/ext The multi-versioning of the t/ directory seems critical, because the tests in the YAML smokes are identified by line number, and the correspondence will be wrong if the test has changed. Therefore I'm afraid that a redirect to a single version of t/ won't suffice. The way I wrote the patch so far, checkouts of old t/ revisions would be cleaned up at the same time as the corresponding smoke. If the load of an SVN checkout (just of t/) upon smoke submit is too much, maybe we should migrate to a different server. It seems there are only a couple smokes submitted daily. Would it be too much load on feather? Alternatively, we could have the client send the whole t/ directory with the smoke report. Christopher
Re: synopses on smoke server
Hi, Christopher D. Malon wrote: Currently, the smokeserver does not run smartlinks.pl etc., but redirects to tests.pugscode.org via .htaccess: Redirect /iblech/stuff/pugs-smokes/t http://tests.pugscode.org/t Redirect /iblech/stuff/pugs-smokes/ext http://tests.pugscode.org/ext The multi-versioning of the t/ directory seems critical, because the tests in the YAML smokes are identified by line number, and the correspondence will be wrong if the test has changed. Therefore I'm afraid that a redirect to a single version of t/ won't suffice. ah! I didn't realize that. If the load of an SVN checkout (just of t/) upon smoke submit is too much, maybe we should migrate to a different server. Running svn a few times a day is really not an issue :) --Ingo
gather/take definition missing
I found 6 references to gather in Perl6/Spec/*, but none of them were a formal definition. It would great if an official entry for gather/take could be added. Mark
[perl #40292] [TODO] Add JSON tests
# New Ticket Created by Will Coleda # Please include the string: [perl #40292] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40292 There is now a JSON compiler: perldoc compilers/json/JSON.pir We need more tests (t/compilers/json/to_parrot.t) that test the _dumper() output of a PMC generated by converting from a JSON string. E.g.: Would convert to an empty string, which would then be dumped as: JSON = See http://www.json.org/ for a description of the JSON grammar: all elements of that grammar should be tested. For failing tests, TODO them, and I'll be happy to fix the compiler. Unless you beat me to it, which is fine. As of the opening of this ticket, expect arrays and objects to fail (need TGE support), true/false/null to work, and strings numbers to partially work. Regards. -- Will Coke Coleda [EMAIL PROTECTED]
[svn:parrot-pdd] r14452 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:05 2006 New Revision: 14452 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Move pdd07 out of clip Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
[svn:parrot-pdd] r14453 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:18 2006 New Revision: 14453 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
[svn:parrot-pdd] r14454 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:40 2006 New Revision: 14454 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
[svn:parrot-pdd] r14455 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:46 2006 New Revision: 14455 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: About 25% done with update of pdd07. Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
pls ignore commits w/o content
It seems that I've managed to confuse svk again, as it continues to re-commit old log messages with no content. -- Chip Salzenberg [EMAIL PROTECTED]
