Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Start a nNew thread

Re: possible sscanf misfeatures
by Mirar ＠ Pike developers forum 22 Jun '11

22 Jun '11

> sprintf("%+2c",17); (26) Result: "+\0\21" Can't ever be what you want...

1 0

foreign_ident frustration
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 17 Apr '11

17 Apr '11

I'm getting quite fed up fiddling with those foreign_ident markers. A serious problem is that the changes in .gitattributes makes it cumbersome to cherry pick patches between branches and reorder commits (before push, of course). The .gitattributes diffs also preclude the possibility for git to recognize the same patch on the different branches. Another annoyance is that the commit checks get in the way: I never remember to check for foreign_idents before committing, so the commit get interrupted and I have to salvage the commit message (which in the case of using MaGIT in Emacs is definitely lost). Often it's also necessary to reset the file to get the $Id$ expansion right, which means I have to restage the commit with chunks and everything. On top of that there's various strange behavior in git with "spook differences" when the $Id$ handling changes. E.g. today I got into a state with a file where git reset/checkout resulted in it being considered changed in the $Id$ expansion right from the start. Killing the chunk didn't work, and it simply wasn't possible to get the working tree clean with the intended git tools. Things like this are bugs in git, but be that as it may, they add to the frustration. This foreign_ident system is very proper and correct, but it's frankly a big PITA, and I don't see any benefits with it that even comes close to make it worth the hassle. Keeping the cvs idents around in the historical versions is one thing, but replacing them gradually instead of wholesale is just a little more neat, perhaps. The whole thing boils down to avoiding just a single extra commit. I don't think it's a passing phase either - there are a lot of files, and it'll take a long time for them all to change naturally (it'll probably never happen). Also, the problem with backporting patches will only get worse as the current branch loses more foreign_idents compared to the old ones. So is there a compelling reason to keep those foreign_ident around, or would it be ok to drop them all in one go?

3 5

Re: Calendar.Month / Calendar.Hour
by Marc Dirix 12 Apr '11

12 Apr '11

On 12-04-11 11:20, Mirar @ Pike developers forum wrote: > Or just do ->day(x)->minute(y) or so. :) Yes, but Calendar.Day()->day(-2)->minute(460); for example doesn't work. (At least in 7.8.352): > Calendar.Day()->day(-2)->minute(460); Not in range (Day 1..1 exist). /usr/lib/pike7.8/modules/Calendar.pmod/YMD.pike:818: Day(Tue 12 Apr 2011)->day(0) HilfeInput:1: HilfeInput()->___HilfeWrapper()

2 1

Calendar.Month / Calendar.Hour
by Marc Dirix 12 Apr '11

12 Apr '11

Hi, Pike 7.8.352 (Debian) In hilfe: > Calendar.now(); (21) Result: Fraction(Thu 7 Apr 2011 12:26:15.216691 CEST) > Calendar.Hour()+Calendar.Minute(); (22) Result: Minute(Thu 7 Apr 2011 12:01 CEST - 13:01 CEST) > Calendar.Month()+Calendar.Minute(); (23) Result: Minute(Fri 1 Apr 2011 0:01 CEST - Sun 1 May 2011 0:01 CEST) So Hour is calculated from the beginning of the last hour + 1 minute, and Month calculates starting of the month until next month + 1 minute. I expected the behaviour to be the same as with Calendar.Hour()? Best regards, Marc Dirix

4 6

Re: Calendar.Month / Calendar.Hour
by Marc Dirix 09 Apr '11

09 Apr '11

Thank you for thinking with me! I know the number of minutes, I just have to convert them to a date so I can test if current-time >= schedule-time. I think I need something along the lines of: next = Calendar.Day()->beginning() + Calendar.Minute()*x; or for tomorrow: next = Calendar.Day()->end() + Calendar.Minute()*x; /Marc

3 5

call_outs
by Arne Goedeke 07 Apr '11

07 Apr '11

I was about to change backend.cmod to use power of two hashtables, aswell. Its using hash_svalue anyhow, and it seems a little unnecessary to use mod prime hashtables there. Anyhow, while doing so and putting some benchmarks together I noticed that the code in backend.cmod:990 ff assumes that is_eq has side effets. Because of that it does alot of extra work. Its especially bad if one has alot of callouts to the same function since the buckets get very large. If a call to remove_call_out/call_out is the only thing that could change the hash tables, we might aswell do some kind of recursion detection and error instead (in case someone does call_outs from `==). Any thoughts? arne

4 11

Re: Calendar.Month / Calendar.Hour
by Marc Dirix 07 Apr '11

07 Apr '11

I need to calculate a time based on the number of minutes since the start of the month, or since the start of the day. Calendar.Day()+Calendar.Minute()*x always worked fine, but Calendar.Month() + Calendar.Minute()* doesn't. But probably I have to revise the code to use beginning() everywhere, also for Calendar.Day(). /Marc

2 1

Re: Calendar.Month / Calendar.Hour
by Marc Dirix 07 Apr '11

07 Apr '11

Ow, my mistake. You're right.

1 0

forced cleanup-on-exit
by Arne Goedeke 02 Apr '11

02 Apr '11

I am currently writing a cmod for some obscure piece of hardware. Its driver tends to generate kernel panics if some deinitialization does not happen. It would therefore be nice if it was somehow possible to force the destruction of certain objects on exit, even without --with-cleanup-on-exit. Is there a possibility for that? And no, I cannot fix the kernel driver ;-)

3 4

32 bit abi crashes on darwin
by H. William Welliver III 01 Apr '11

01 Apr '11

I just tried to compile 7.8.352 on a new core i7 box running OSX 10.6 using 32-bit abi and the build fails because the pike generated crashes somewhere in the machine code generation. I compiled using the following command line: make CONFIGUREARGS="--with-abi=32" The backtrace looks like this: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000004f 0x000c0227 in ia32_flush_instruction_cache (start=<value temporarily unavailable, due to optimizations>, len=55) at ia32.c:1047 1047 __asm__ __volatile__(".byte 0x0f\n" (gdb) bt #0 0x000c0227 in ia32_flush_instruction_cache (start=<value temporarily unavailable, due to optimizations>, len=55) at ia32.c:1047 #1 0x0012e61e in eval_low (n=0x838d78, print_error=1) at /Users/hww3/Downloads/Pike-v7.8.352/src/las.c:5241 #2 0x0000b48b in yyparse () at language.yacc:660 #3 0x000ee199 in f_compilation_compile (args=0) at /Users/hww3/Downloads/Pike-v7.8.352/src/program.c:8213 #4 0x0001697b in low_mega_apply (type=APPLY_LOW, args=0, arg1=0x831fb4, arg2=0x1) at apply_low.h:226 #5 0x000181cc in mega_apply (type=APPLY_LOW, args=0, arg1=0x831fb4, arg2=0x1) at /Users/hww3/Downloads/Pike-v7.8.352/src/interpret.c:2211 #6 0x000185b0 in apply (o=0x831fb4, fun=0x1ecfbf "compile", args=0) at /Users/hww3/Downloads/Pike-v7.8.352/src/interpret.c:2604 #7 0x000d939f in f_compilation_env_compile (args=1) at /Users/hww3/Downloads/Pike-v7.8.352/src/program.c:7828 #8 0x0001697b in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x831fdc, arg2=0x1) at apply_low.h:226 #9 0x000181cc in mega_apply (type=APPLY_LOW, args=1, arg1=0x831fdc, arg2=0x1) at /Users/hww3/Downloads/Pike-v7.8.352/src/interpret.c:2211 #10 0x00145d5c in f_compile (args=1) at /Users/hww3/Downloads/Pike-v7.8.352/src/builtin_functions.c:4229 #11 0x000c83ae in get_master () at /Users/hww3/Downloads/Pike-v7.8.352/src/object.c:643 #12 0x000c85bb in debug_master () at /Users/hww3/Downloads/Pike-v7.8.352/src/object.c:689 #13 0x000b61cc in load_pike_master () at /Users/hww3/Downloads/Pike-v7.8.352/src/pike_embed.c:468 #14 0x000022e8 in main (argc=1, argv=0xbffff804) at /Users/hww3/Downloads/Pike-v7.8.352/src/main.c:629 Of course, things work fine using 64 bit ABIs, but I have a need to use some libraries that are 32 bit only, which of course makes everything more complicated. I'm going to assume that it's not something I've done wrong, but please do let me know if my assumption is incorrect :) Thanks in advance, Bill

5 6

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