Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Start a nNew thread

Regexp.PCRE problem
by Mirar ＠ Pike developers forum 27 Jun '04

27 Jun '04

I'll patch away those lines now.

1 0

Language Shootout
by Peter Bortas (Kein Paket!) ＠ Pike (-) developers forum 23 Jun '04

23 Jun '04

It seems someone has taken it upon himself to maintain the Great Computer Language Shootout for a bit again: http://shootout.alioth.debian.org/

4 7

String.Buffer foo
by Mirar ＠ Pike developers forum 23 Jun '04

23 Jun '04

| % pike | Pike v7.7 release 3 running Hilfe v3.5 (Incremental Pike Frontend) | > string test="hej"; | > String.Buffer buf=String.Buffer(); | > (string)(buf+test[3..]); | (1) Result: "" | > buf+="hej"; | (2) Result: Buffer(3 /* 512 */) | > (string)(buf+test[3..]); | zsh: segmentation fault pike

1 0

pike, sTeam and caudium at the linuxtag 2004
by Martin Bähr 21 Jun '04

21 Jun '04

hi, we have again been given the opportunity to present pike at the linuxtag in germany. from the 23rd to the 26th of june we will be able to present pike together with caudium and sTeam. please make suggestions on what to present, to make pike interresting to the public. who is willing to come to karlsruhe? if you bring a sleepingbag there is free accomodation. if you are interrested please contact me. (even if you are not sure you can make it, you don't need to commit right away) http://www.linuxtag.org/2004/ http://www.linuxtag.org/2004/community/pavillon.html http://www.infodrom.org/Debian/events/LinuxTag2004/projects.php3 http://www.infodrom.org/Debian/events/LinuxTag2004/faq.html greetings, martin. -- looking for a job doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer travelling and working in europe open-steam.org unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (stuts|black.linux-m68k).org is.schon.org Martin Bähr http://www.iaeste.or.at/~mbaehr/ _______________________________________________ Caudium-general mailing list caudium-general(a)caudium.net http://lists.oav.net/wws/info/caudium-general Archives are : http://lists.oav.net/wws/arc/caudium-general Caudium Website : http://caudium.net/

3 3

Re: scopes and destructors
by Stephen R. van den Berg 18 Jun '04

18 Jun '04

Martin Stjernholm wrote: >"Stephen R. van den Berg" <srb(a)cuci.nl> wrote: >> Ideal methods are threadsafe, and should be able to handle >> themselves in all cases. >Hardly relevant since pike isn't a toy for language purists. We don't >want to add thread safety in every function since it adds complexity >and overhead (and besides I don't see any way for the language to >enforce it without seriously crippling thread support). The same goes >for wrappers to avoid cycles. I think we're talking past each other here. I'm not saying that the language should enforce thread safety or anything else. I'm just saying that someone writing a class, should try to make the class threadsafe. >It's not hard to deal with these implicit properties if one only is >aware of them. It's much more efficient and imho also easier to treat >them as properties objects might or might not have, just like the >existence and type of any identifier. >Pike isn't alone in this. At least C++ and Java allow similar implicit >properties in object behavior, and I'd wager most other real world OO >languages do too. Yes, like I said above, that's a Good Thing. But that doesn't mean that someone writing a class should avoid these special properties if at all possible without excessive cost. >> Calling the destructors can be done, without freeing the actual memory; >> /.../ >No. Consider the case when there's an array, mapping or something else >that indirectly might contain objects. You have to free it to be sure >that the appropriate objects are destructed. I disagree (but, most likely, I still have the privilege to do this, because I'm not aware of the exact implementation Pike picked). Even if there's an array, mapping or something else that indirectly might contain objects; then it is not necessary to free this structure, it is only required to *traverse* this structure scouting for objects which have actual destructors defined. The actualy memory footprint can be left alone. But, for all I know, traversing the structure might be more difficult than simply freeing it. >> Besides, given the fact that programmers usually only use scopes within >> a function to limit the scope of a variable because they want to save >> memory, /.../ >Actually, that's not how I commonly use it. Most of the time I use it >to limit the visibility of the identifier to the narrowest possible >scope. In these cases I don't much care about when the memory really >is released. Ok, another possibility. I do this myself as well, but it's a practice I don't see a lot by anyone else. >Anyway, the memory has to be freed sooner or later anyhow, so the only >speed lost would be due to slightly larger code and some more >twiddling of the stack pointer, and I think that's negligible. I'd say the same (without knowing as much about the Pike implementation). >>>Note that inner functions make it a bit complicated to implement >>>popping at the end of scopes. Consider this case: >> That I realise. But that's a problem with actually freeing the memory, >> not with calling the destructors. >Sorry, but the same goes for destruction itself. It's trivial to adapt >my example so that there's an object that shouldn't be destructed when >the block is exited. Undoubtably true, but this discussion is not that important, since it will follow whatever constraints are given for correct operation. I just want to destruct objects which lose scope. If the object should be longer lived because of some reason, then so be it, then don't call the destructor yet. >> Ok, since we agree on the target. Any ideas on where to look in the >> Pike source? >Assuming that my suggestion from the other mail works, it's docode.c, >interpret_functions.h, language.yacc and probably a bunch of others. >Welcome to the world of the compiler and interpreter internals. ;) I'm not afraid. I did GCC development for more than a year, quite intensively in 1993-1995 (developing x86 register passing (coded in 14 days) and ending up fixing more collateral damage than I ever bargained for, all needed to support the 14 day hack for register passing). >(Moving the discussion to the pike devel list since it's clearly about >pike development now.) Ok, I just subscribed. On a related note, can I have write access to the Pike CVS repository? I agree to the rules. I promise to be a good boy. My username on the lysator.liu.se system for CVS is _cvs_stephen I'm already using it in the ChiliMoon project. I presume it can be reused for Pike. I'd need the CVS coordinates of the repository. I also wonder why the codelibrarian on lysator doesn't show Pike? To mast: Yes, I know that many of my suggested patches to Roxen have the appearance of being a bit shortsighted. That's not usually my practice of doing things. This behaviour is driven by the fact that (over the years) I've noticed that Roxen is slow in responding to bug reports/patch suggestions. So in order to make the chance of acceptance high, I minimise the change, so it's more easily understood. The other reason is that changes which have minimal impact on existing code, allow me to maintain long-term diff-versions of Roxen, without the need to check for conflicts every time the master source changes. Changing more to get better code (designwise), makes for larger exposure to change-conflicts. This is bad if you know that some changes will not get in for at least three years. In ChiliMoon you'll eventually be able to see what the remaining patches should have looked like (the ugly DB-patches you're still sitting on, are next on the list now (since Pike has been adapted now :-)). -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files." -- SysV.2 manual

2 1

fmod
by Mirar ＠ Pike developers forum 16 Jun '04

16 Jun '04

Anyone imlemented a glue for fmod to Pike (or are working on it)?

1 0

fmod
by Mirar ＠ Pike developers forum 16 Jun '04

16 Jun '04

footnote: http://www.fmod.org

1 0

checking if the JVM really works...
by David Gourdelier 15 Jun '04

15 Jun '04

Hi, Looks like there is a problem with Pike's configure and Java. I have the latest JRE and Pike's configure says: configure:3922: checking if the JVM really works configure:4005: gcc -o conftest -g -I. -I/usr/local/j2ee/jdk/jre/../include/linux -I/usr/local/j2ee/jdk/jre/../include -L/usr/local/j2ee/jdk/jre/lib/i386 -R/usr/lo cal/j2ee/jdk/jre/lib/i386 -L/usr/local/j2ee/jdk/jre/lib/i386/native_threads -R/usr /local/j2ee/jdk/jre/lib/i386/native_threads -L/usr/local/j2ee/jdk/jre/lib/i386/ser ver -R/usr/local/j2ee/jdk/jre/lib/i386/server -L/usr/local/j2ee/jdk/jre/lib/i386/c lient -R/usr/local/j2ee/jdk/jre/lib/i386/client conftest.c -ljvm >&5 gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/native_threads' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/server' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/client' configure:4008: $? = 0 configure:4010: ./conftest ./conftest: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory gcc (GCC) 3.3.3 (Debian 20040422) Pike 7.6 / David

5 14

Broken ADT.Priority_queue?
by Marcus Agehall (Scanian) ＠ Pike (-) developers forum 14 Jun '04

14 Jun '04

I just tried to use ADT.Priority_queue like this: object q = ADT.Priority_queue(); q->push(1,1); q->pop(); and this code hangs my computer almost completely using Pike 7.7 from CVS. Can someone reproduce the problem or tell me if I'm doing something wrong in my code?

2 2

segfault in red-black?
by Mirar ＠ Pike developers forum 13 Jun '04

13 Jun '04

How interesting is this? Should I persue it further? (Pike 7.7 from CVS tuesday.) Program received signal SIGSEGV, Segmentation fault. 0x080c28d0 in multiset_delete_node (l=0x82fd00c, nodepos=1) at /home/mirar/pike/src/multiset.c:2559 2559 while (RBNODE (node) != existing) LOW_RB_TRACK_PREV (rbstack, node); (gdb) bt #0 0x080c28d0 in multiset_delete_node (l=0x82fd00c, nodepos=1) at /home/mirar/pike/src/multiset.c:2559 #1 0x080bfec4 in multiset_next (l=0x82fd00c, nodepos=2) at /home/mirar/pike/src/multiset.c:1757 #2 0x08127a6f in foreach_iterate (o=0x85e8b28, do_step=1) at iterators.cmod:1944 #3 0x0807189f in test_opcode_F_FOREACH_LOOP () at interpret_functions.h:1416 #4 0x083eadf3 in ?? () #5 0x00000011 in ?? () #6 0x00000001 in ?? () #7 0x0000000f in ?? () #8 0x4020d6d0 in __after_morecore_hook () from /lib/libc.so.6 #9 0x4020cc40 in ?? () from /lib/libc.so.6 #10 0xbfffee20 in ?? () #11 0x000000d2 in ?? () void draw2() { Node node1=this; -> foreach (indices(links);;Node node2) { passed->line(node1->x,node1->y, node2->x,node2->y, 255,0,0); } }

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel