Pike-devel April 2012

pike-devel@lists.lysator.liu.se

7 participants
20 discussions

Sql.pgsql behavior in case of errors
by aldem-pikedev＠aldem.net 21 Aug '14

21 Aug '14

Hi everyone, I am preparing to use Postgres in my app, found the following strange behavior: ---snip--- Sql.Sql db = Sql.Sql("pgsql://localhost", "test", "test", "test"); db->query("BEGIN"); db->query("INSERT INTO requests (SvTrId) VALUES ('lala')"); catch(db->query("INSERT INTO requests (SvTrId) VALUES ('lala')")); db->query("INSERT INTO requests (SvTrId) VALUES ('juju')"); db->query("ROLLBACK"); ---snip--- Database is opened, row with 'lala' is inserted, second query (obviously) fails as SvTrId is the primary key, but row with 'juju' is inserted *and* appears in the database - i.e. the transaction is *committed*! Studying source code show, that once error is encounter, session is reset, i.e. running transaction is rolled back, everything is closed, temporary tables are deleted and session variables are reset as well, and after that, the next statement(s) will be committed immediately, as there is no active transaction. In my opinion, this is not exactly correct behavior when statement fails, as session still may be needed (especially temporary tables, open cursors etc). Im some cases, this is perfectly normal when SQL statement fails, especially in SERIALIZED transaction isolation level, and it would be more practical to leave the decision as of what to do to the application. Yes, this is true that it is impossible to continue executing statements in failed transaction, but temporary tables etc. may still be needed. Also, silent reconnection is not a good idea too - when there are many transactional statements are executed - it would be nice to have an option to modify this behavior. Best regards, /Alexander

5 6

Pike 7.8 Beta
by H. William Welliver III 13 May '12

13 May '12

I've prepared a new 7.8 test release for consideration. Please feel free to download and test. http://pike.ida.liu.se/download/pub/pike/beta/7.8.680/ I am not aware of any show stoppers in this release; if none are found in the next week, this will become the new stable 7.8 release. As always, please feel free to get in touch with any comments or concerns. Best, Bill bill(a)welliver.org

6 16

Metafunctions
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 27 Apr '12

27 Apr '12

I've got a bit of a problem with the `->() lfun. To illustrate, consider the following class: ---8<-- class Base { mixed `->(string x) { return (x == "add_one" && lambda(int x) { return x+1; }) || (x == "add_two" && lambda(int x) { return x+2; }); } } ---8<--- I now have a class which allows me to do Base()->add_one(7) to get 8, and Base()->add_two(7) to get 9. So far so good. Now, let's try to specialize this class: ---8<--- class Sub { inherit Base; string add_two(int x) { return x+"two"; } } ---8<--- FAIL! Sub()->add_two(7) still returns 9. And what's more, even if I try to add something with a name that doesn't exist in Base, I still can't access it outside of Sub. Is there a way around this? I tried using `::->() as a fallback in `->(), but it didn't have the desired effect.

2 4

Pike 7.8 beta: feedback?
by Bill Welliver 25 Apr '12

25 Apr '12

So, 7.8.680 has been out and about for a week, and despite the fact that I checked a fix in after I made that build, I'm inclined to say .680 should become an official release. Does anyone have any feedback? Go? No go? Bill

2 1

Segfault
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 23 Apr '12

23 Apr '12

I get this crash when trying to build pike with dmalloc. #### Making dynamic: post_modules/GTK2 make[2]: Entering directory `/home/nilsson/pike/dmalloc/post_modules/GTK2' Makefile:576: warning: overriding commands for target `depend' Makefile:332: warning: ignoring old commands for target `depend' /home/nilsson/pike/dmalloc/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/nilsson/pike/dmalloc/master.pike /home/nilsson/pike/src/post_modules/GTK2/build_pgtk.pike --source='/home/nilsson/pike/src/post_modules/GTK2/source/' \ /home/nilsson/pike/src/post_modules/GTK2/output/few.pike make[2]: *** [compile1] Segmentation fault make[2]: Leaving directory `/home/nilsson/pike/dmalloc/post_modules/GTK2' make[1]: *** [GTK2] Error 1 make[1]: Leaving directory `/home/nilsson/pike/dmalloc/post_modules' make: *** [post_module_objects] Error 1 And it looks like it is in the startup things bail out. nilsson@riaa:~/pike/dmalloc$ gdb pike GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /home/nilsson/pike/dmalloc/pike...done. (gdb) run -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/nilsson/pike/dmalloc/master.pike Starting program: /home/nilsson/pike/dmalloc/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/nilsson/pike/dmalloc/master.pike [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. parent_clone_object (p=0x0, parent=0x2b72a60, parent_identifier=3, args=0) at /home/nilsson/pike/src/object.c:410 410 if(!(p->flags & PROGRAM_PASS_1_DONE)) (gdb) bt #0 parent_clone_object (p=0x0, parent=0x2b72a60, parent_identifier=3, args=0) at /home/nilsson/pike/src/object.c:410 #1 0x00000000005b1569 in compile_compiler () at /home/nilsson/pike/src/program.c:9751 #2 init_program () at /home/nilsson/pike/src/program.c:10304 #3 0x0000000000544245 in init_pike_runtime (exit_cb=0x4127e0 <exit@plt>) at /home/nilsson/pike/src/pike_embed.c:393 #4 0x0000000000413fb4 in main (argc=4, argv=0x7fffffffe078) at /home/nilsson/pike/src/main.c:609

2 3

Re: new block allocator
by Tobias S. Josefowitz 22 Apr '12

22 Apr '12

On Mon, Apr 16, 2012 at 12:30 AM, Martin Stjernholm, Roxen IS @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Just to make it clear, you're talking about the linear lookup to find > the right block when structs are freed? Yes. >> No, std::allocator is a block allocator used by std::list, std::map >> and so on. Compared to glibc free/malloc, the std::allocator is quite >> fast. > > It would be interesting to see a comparison with plain old (glibc) > malloc, just to put it into perspective. There is updated graphs on https://github.com/arneg/GJAlloc/wiki/Performance-comparison. Turns out, in fact, I misattributed benefits to the std::allocator it does not have. >> Slight ones. For the CritBits, we need the allocator in the object >> storage (block allocators are used tree-locally). > > So the nodes for each critbit tree are allocated within its own blocks? > Sifting through the code just briefly I got the impression the nodes > were allocated from a single global pool, considering that > CB_NODE_ALLOC() doesn't take any context. Did I miss something? And my bad again. Currently the code does not do this, for comparability between the two block allocators as used by CritBits, I think. >> http://fortranland.com/compare_7.9_block_alloc.txt >> http://fortranland.com/compare_7.9_block_alloc_cleanup_on_exit.txt > > Hmm, do you have any theories to explain the variations seen in those > two? Currently, no explanation that would make you go "Ah ok, in that case, sure." is available. Especially not any based on facts :). > Otherwise it seems to me like there's still a lot of noise, and I > suspect none of those tests really stress BLOCK_ALLOC in the way where > your implementation would show its strength, i.e. freeing structs when > there's a large number allocated. > > I figured I could add a test for that, but I can't compile CritBit from > clean source on the arne/block_alloc branch: > > #### Making dynamic: post_modules/CritBit > make[5]: *** No rule to make target `/home/mast/Pike/devel/src/post_modules/CritBit/bitvector.h', needed by `inttree.o'. Stop. > make[4]: *** [all] Error 2 > make[3]: *** [CritBit] Error 1 That seems to be either an issue with dependencies, or you need to touch src/post_modules/CritBit/*.cmod, or both. In arne/block_alloc, bitvector.h was moved from src/post_modules/CritBit/ to src/ - any chance, your src/post_modules/CritBit/dependencies has size > 0? > And of course, a couple of CritBit benchmarks would be welcome - they > also ought to show off GJAlloc, right? ;) That can be arranged.

3 7

Re: new block allocator
by Tobias S. Josefowitz 22 Apr '12

22 Apr '12

On Tue, Apr 3, 2012 at 12:35 AM, Martin Stjernholm, Roxen IS @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: >> We pushed an experimental branch which uses a new block allocator we >> have been developing. /.../ > > I guess you already told us at the conference, but what was your > motivation for creating it? The linear lookup in the existing one... > > Is std::allocator the same thing as the (g)libc malloc in your graphs? No, std::allocator is a block allocator used by std::list, std::map and so on. Compared to glibc free/malloc, the std::allocator is quite fast. > I take it you already got it working as a replacement for the old > BLOCK_ALLOC, including that quirky heap walker that the old one > sports? Do you have any test where they are compared? We used pike -x benchmark (because results there jitter a lot we averaged ~160 runs, which seems to give useful precision). I will dig up some results from that. However, -x benchmark may not at all be what should be used for meaningful comparison, but unfortunately we did not come up with anything better yet. > >> /.../ Currently, GJAlloc is requested as a bundle by the CritBit >> module, which uses its API directly. > > Does it add any features? Slight ones. For the CritBits, we need the allocator in the object storage (block allocators are used tree-locally). Other than that, GJAlloc supports ba_free_all() and ba_destroy(). > >> All other modules use macro definitions which are compatible with the >> ones from block_allocator.h. > > You mean the old block_alloc.h? Yes, that we meant. best, tobi

4 6

Re: new block allocator
by Tobias S. Josefowitz 22 Apr '12

22 Apr '12

> I'd rather have it directly in the source than as a bundle, but I > guess it's up to you really. We do not want to keep anyone from working on it, of course. Just the idea of releasing this also "standalone" as a block allocator package seemed interesting, and still is. The current GJAlloc even includes some C++ code so that GJAlloc can be used instead of std::allocator and so on, where applicable. All of this (or at least the parts concerning Pike) certainly could be managed in the Pike tree and then from time to time made into a .tar.gz release of the allocator. However, what if we moved the allocator development git repository right next to the Pike repository, same ACLs as pike.git? We would also give out access to the github repository readily, of course, but that does not seem like a particularly smart process. In any case, suggestions on how to achieve a good process for both Pike and standalone releases are more than welcome.

3 2

Re: Pike 7.8 Beta
by Oleksii Prudkyi 19 Apr '12

19 Apr '12

18.04.12 21:35, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum написав(ла): > Built and verified ok on Ubuntu/ppc, Ubuntu/armhf, Debian/amd64 and > Solaris11/sparc. I am checked on OpenSuse i686 and look like it ok. and, two questions with building process: - is here exists easy way to "remap" system to use not-installed pike , i.e. some from ~/apps/Pike-v7.8.680 - is it possible to build pike without pike installed ? Best regards, Oleksii Prudkyi

2 1

mime type update
by Bill Welliver 16 Apr '12

16 Apr '12

Any objections to adding a few newish popular mime types to the MIME extension database? Specifically, I was thinking about the ODT types, but would be glad to add others if someone cares to send them my way. Bill

2 1

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 April 2012