Pike-devel

pike-devel@lists.lysator.liu.se

3044 discussions

#if constant again
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 02 Jul '04

02 Jul '04

I see Nilssons latest changes has broken the #if constant check again. Is it intentional since there still seems to be a difference in opinion on that, or is it just a confused attempt to make the warning at master.pike:586 optional? In 7.6, the errors for placeholders also are relegated to warnings. Nilsson, can you explain that? Btw, I applaud the initiative to add Pike_vsnprintf. The implementation is a bit simplistic, but it's a start. It does handle wide strings correctly, doesn't it?

2 1

Interpreter locks, I/O, FD_BOXES and the Shuffler
by Stephen R. van den Berg 01 Jul '04

01 Jul '04

As I understand it, the Shuffler, before the callback mechanism was changed in the backend, was using a method which bypassed the Pike interpreter lock to actually shuffle out large amounts of data. How do I check if the new method exercises the lock or not? What do I need to watch out for if I'd like to improve on that? -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "The difficult we do today; the impossible takes a little longer."

1 0

Regexp.PCRE problem
by Alexander Demenshin 27 Jun '04

27 Jun '04

Hi, There is one problem with Regexp.PCRE when study() is called (or Regexp.PCRE.Studied()). exec() code (in cmod) contains the following: ---snip--- #ifdef PCRE_EXTRA_STUDY_DATA if (THIS->extra) opts|=PCRE_EXTRA_STUDY_DATA; #else /* FIXME: Throw an error if THIS->extra is set? */ #endif /* PCRE_EXTRA_STUDY_DATA */ ---snip--- and opts will be used later in call to pcre_exec(), but.. this is a bit incorrect, since this option should be set not in the call to pcre_exec(), but in pcre_extra struct (field "flags"). Hence, any call to exec()/split() etc. for studied PCRE gives an error (with PCRE 4.4): > Regexp re = Regexp.PCRE("([a-z]+)"); > re->split("123abc123"); error returned from exec: ERROR.BADOPTION In case of PCRE 3.9, it passes by, but it is only because there is no symbol PCRE_EXTRA_STUDY_DATA defined. Additionally, PCRE doc says (man pcreapi): ---snip--- Other flag bits should be set to zero. The study_data field is set in the pcre_extra block that is returned by pcre_study(), together with the appropriate flag bit. You should not set this yourself, but you can add to the block by setting the other fields. ---snip--- So, there is absolutely no need to pass any options to pcre_exec() call while handling exec(). I would commit a fix, but I am not sure how to regenerate file pcre_glue.cmod.compiled - or is it enough to make change in cmod and .compiled will be (re)generated automatically? Also, side note - the ovector size is defined as 3000 - isn't this an overkill for most cases? It will consume 12K of stack space with every call to exec() (at least, this space is not dynamically allocated, which would be even worse). Regards, /Al

3 3

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

Jump to page:

2026

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