Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Re: 9233989: ecx and edx were mixed up
by Chris Angelico 28 Sep '15

28 Sep '15

On Tue, Sep 29, 2015 at 12:40 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Well, I didn't actually change the order. But I see that the code in > cpulib outputs them differently depending on which assembler code is > used, which is bad of course. Fixing that should make ia32 work with > all compilers. Ah, I didn't notice that it varied according to which assembler is being used. What I saw was this: #ifdef CL_X86_ASM_STYLE __asm { mov eax, oper; mov edi, cpuid_ptr; cpuid; mov [edi], eax; mov [edi+4], ebx; mov [edi+8], edx; mov [edi+12], ecx; }; which definitely stashes them into memory in order EAX/EBX/EDX/ECX, which corresponds to the comment. I'm not familiar with the other syntax, which uses =a, =r, =c, =d, but since you switched those, I'm assuming they correspond to the Accumulator, Result??, Counter, and Data registers. Thanks! ChrisA

2 1

9233989: ecx and edx were mixed up
by Chris Angelico 28 Sep '15

28 Sep '15

For operation 0, the text string is indeed returned in [EAX]/EBX/EDX/ECX. However, the string is used only in src/code/ia32.c for its detection of AMD vs Intel, so it's entirely possible this change won't break anything anywhere else. Might merit a comment and some odd code in that one file, rather than warping other files around the oddity of that operation. Thoughts? ChrisA

2 1

Pike 8.0 release schedule
by H. William Welliver III 21 Sep '15

21 Sep '15

Hello all, The time has come for an official release of Pike 8.0! Because this is something that we all want but since we have trouble settling on a plan, it’s been decided that the release date for the first stable Pike 8.0 release will occur on Thursday, October 15. I will make a release candidate on October 8, and if it passes the testsuite on my limited set of test machines, I think we will be good to go. Please take a moment to run “make verify” on your system and report any problems not of your own making. This is a hard date, so if you’ve got something you’ve been putting off, or some buggy code you’ve been meaning to fix, my suggestion would be to make that a priority now. :) Also, please don’t commit the rewrite of the type system you’ve been dabbling with, or anything else major that hasn’t already been discussed and agreed to. This one month warning is a chance to get anything that needs final polish or documentation (hint, hint) sorted out. Also, If you’re feeling especially considerate, please take a moment to document your changes in the change log. This will save me a lot of time in the upcoming weeks. If you’ve got any questions, comments or concerns, please feel free to drop me a note personally or to the list generally. Thanks in advance, Bill

2 2

The type of %
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 08 Sep '15

08 Sep '15

So I thought I would fix that Gmp.mpz(3)%2 has the type mixed. My first quick and dirty fix was to update the type of `% a bit by adding tFunc(tObjIs_GMP_MPZ tInt, tObjIs_GMP_MPZ) Yes, it ignores the int%mpz and mpz%mpz permutations, but it's a start. Not the right one apparently, as I got the following warning when trying it out on Crypto.Random. The code Gmp.mpz random(int top) { return Gmp.mpz(rnd_func( (int)ceil(Math.log2(top)) ), 256) % top; } generates Warning: Wong return type. Warning: Expected: { mpz = object(implements _static_modules.Gmp()->mpz) }. Warning: Got : object(is _static_modules.Gmp()->mpz) | mixed. Why is there a "| mixed" in this type? Is this at all the correct approach? Can we get nicer names than _static_modules.Gmp()->mpz?

2 4

Re: New Defects reported by Coverity Scan for Pike-master
by Chris Angelico 07 Sep '15

07 Sep '15

On Tue, Sep 8, 2015 at 12:28 AM, <scan-admin(a)coverity.com> wrote: > 1614 case TWO(STRING_ALLOC_SUBSTRING,1): > 1615 Pike_fatal("This should not happen, substrings are never unlinked.\n"); >>>> CID 1323178: Control flow issues (MISSING_BREAK) >>>> The above case falls through to this one. > 1616 default: Shouldn't Pike_fatal be marked as a non-returning function? ChrisA

2 1

split-string branch
by Per Hedbor () ＠ Pike (-) developers forum 01 Sep '15

01 Sep '15

Would it be OK to merge the split string code to pike 8.1? I have done the merge to a private branch, and now wonder if it would be OK to push it upstream. It splits strings into two parts: The pike_string structure and the actual string. There are at least two advantages that are available right now: 1: "static" strings (C-strings and static C-data) can be converted to pike strings without allocating any memory for the string data. This actually saves measurable amount of string bytes. Also, these strings are faster to create since there is no need to allocate storage for the actual string data (useful as an example in GTK2, there is an actual measurable speedup in the init of that function. Well. microseconds, but it's faster. :)) 2: It actually improves the speed of some string operations, probably because the string metadata is closer in memory (more likely to be cached). The disadvantages are, at least: 1: one more pointer in the string struct. This is, however, balanced for everythinge except short strings by the fact that malloc is not used to allocate them, so there is one less size_t in them (malloc overhead) 2: string data is individually mallocd (see 1), so here we get the overhead back, except for short strings. :) So, basically: 8 bytes more overhead for strings. As for the speed of string creation/free:ing: Without patch: | String Creation . . . . . . . . . . . . . . . . . . 2207k/s | String Creation (existing) . . . . . . . . . . . . 8335k/s With patch: | String Creation . . . . . . . . . . . . . . . . . . 3069k/s | String Creation (existing) . . . . . . . . . . . . 8771k/s Seen this way the split-method is faster for basic string operations. The numbers, however, vary so much that it's basically a wash. Another advantage with this method is that it is reasonably trivial to add new string types. As an example that I am seriously considering: A string that is a tail port of another string. The tail-string would be used for this somewhat unfortunate but rather common coding pattern: sscanf( str, "%2c%s", part, str ); and, in a similar manner: len = file->write(str); str = str[written..] These are both O(n^2), but if tail-of string are added they could both be about O(n), only reallocate the data if more than 50% is wasted. Unfortunately the same can not be done for random substrings, since strings are guaranteed to be 0-terminated. But that is probably not much of an issue in practice. Also, when gc:ing code could be added to "trim" all tail-of strings. There is at least one slightly incompatible change to the C-level API: push_constant_text and the related macros (create a static pike_string the first time it's called, and then use that from now on) now require actual static lifetime of the argument passed to it. This is already the case for all code in the pike tree, but external modules might break this assumption.

4 10

CID[1317352-1317354]
by Peter Bortas ＠ Pike developers forum 27 Aug '15

27 Aug '15

The three new complaints about "Assign instead of compare" in pike_tokenizer looks very, very intentional, but I'll leave it up to whoever introduced them (grubba?) to mark them as false positives.

4 7

Re: C99, variadic macros, and rbtree.c
by Chris Angelico 26 Aug '15

26 Aug '15

On Wed, Aug 26, 2015 at 1:25 AM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > C11 is default since gcc 5.2, I think. But C99 seems to have been > skipped (as the default) entirely. The example line of code that I gave works fine on my system (gcc 4.9.2), but that might be as an extension, not sure. But I have no idea what compilers Pike supports and what C standards they support. ChrisA

2 1

C99, variadic macros, and rbtree.c
by Chris Angelico 25 Aug '15

25 Aug '15

a5a15b makes rb_fatal identical to Pike_fatal when debugging is not active. This doesn't work, because Pike_fatal takes just sprintf format and args, but rb_fatal takes a node pointer first. Since variadic macros exist only in ISO C 1999 and newer, I'm guessing they shouldn't be used; otherwise, it'd be simple to change the definition of rb_fatal to: #define rb_fatal(NODE, ...) Pike_fatal(__VA_ARGS__) What's the best way to go about this? ChrisA

7 7

Re: split-string branch
by Chris Angelico 24 Aug '15

24 Aug '15

On Mon, Aug 24, 2015 at 11:00 PM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >> Since this change does fix the testcase, should I commit it to 8.1? > > Please go ahead and commit it. Pushed. Thanks for the advice! ChrisA

1 0

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