Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Visualization of inherit-graphs
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 11 May '12

11 May '12

6 13

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 24 Apr '12

24 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 15 Apr '12

15 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

map/filter, mapping index/values
by Lance Dillon 12 Apr '12

12 Apr '12

I'm playing with map and filter and stuff, trying to do a functional way of removing an index from a map, like this: ({ ([ "name": "user1", "val": "test", "random": "other" )], ([ "name": "user2", "val": "another test", "random": "something else" ]), }) The array and mapping will be in that kind of format. name is unique among all the map entries, and all the keys exist with all the maps. I want to change it to something like this: ([ "user1": ([ "val": test", "random": "other" ]), "user2": ([ "val": "another test", "random": "something else" ]) ]) I can get the keys for the new map with array[*]["name"]. But removing that key from the maps and leaving the others is giving me a problem. Filter doesn't quite work because it only gives the value, and I'm not testing on the value, but the key. A foreach would work, but I'm wondering if I can do something like: mkmapping(a[*]["name"],map(a,lambda(mapping m) { filter(......something here If anybody has any ideas that would be great... thanks

2 1

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