Fix a compatibility issue with STLport C++ LIB

[GoogleCodeExporter]

Fix a compatibility issue with STLport C++ LIB

Change the the following line in builtin.cpp
int asterisks = count(fmt->unit.begin(), fmt->unit.begin()+j, '*');
to
int asterisks = std::count(fmt->unit.begin(), fmt->unit.begin()+j, '*');

Context:
str *__mod4(str *fmts, list<pyobj *> *vals) {
    int i, j;
    str *r = new str();
    str *fmt = new str(fmts->unit);
    i = 0;
    while((j = __fmtpos(fmt)) != -1) {
        pyobj *p, *a1, *a2;

        int asterisks = std::count(fmt->unit.begin(), fmt->unit.begin()+j, '*');
        a1 = a2 = NULL;
        if(asterisks==1) {
            a1 = modgetitem(vals, i++);
        } else if(asterisks==2) {
            a1 = modgetitem(vals, i++);
            a2 = modgetitem(vals, i++);
        }

        char c = fmt->unit[j];
        if(c != '%')
            p = modgetitem(vals, i++);

        switch(c) {
            case 'c':
                __modfill(&fmt, mod_to_c2(p), &r, a1, a2);

Original issue reported on code.google.com by jason.mi...@gmail.com on 22 Jun 2010 at 8:34

[GoogleCodeExporter]

thanks for the new issues!!! I will try to look into them soon.. as usual, I'm 
a bit burned out after the new release.. :-)

Original comment by mark.duf...@gmail.com on 25 Jun 2010 at 12:40

[GoogleCodeExporter]

thanks again for the patch! because I don't have write access to SVN from china 
at the moment, I decided to move to GIT, something I've been wanting to do for 
a while.. so I applied your patch there, and will be working from there from 
now on:

http://gitorious.org/~srepmub/shedskin/shedskin-srepmub

this is also a temporary repo, until I receive write-access to the 'shedskin' 
repo there that was already created by someone. btw, please send patches as 
diffs instead of decribing them! :) (attach the output of diff -u, svn diff or 
git diff, for example..)

oh, I'm also a bit curious as to why you are testing with STLport..? :-)

Original comment by mark.duf...@gmail.com on 30 Jun 2010 at 3:56

• Changed state: Fixed

[GoogleCodeExporter]

make that http://gitorious.org/shedskin.. :-)

Original comment by mark.duf...@gmail.com on 30 Jun 2010 at 4:12

[GoogleCodeExporter]

STLport lib has better performance than MSVC in vector insert operation  :)
BTW, Are you travelling in China for vacation ?

Original comment by jason.mi...@gmail.com on 1 Jul 2010 at 1:44

[GoogleCodeExporter]

I see. are you sure you cannot use a faster dastastructure, if this is an 
important operation for you..?

in the end, we'll probably want to write our own list/tuple implementation, 
based on CPython, just like FFAO did for the set/dict implementations.. so it 
won't be possible to use different STL versions.

it's sort of a vacation, but I'm staying with the family of my wife, so I can 
work here most of the time, if necessary.. :-)

Original comment by mark.duf...@gmail.com on 1 Jul 2010 at 4:34

[GoogleCodeExporter]

My algorithm involves many insertion operation for LIST. You know, LIST is 
implemented in python in array/vector, O(n) for non-tail insertion. The best 
suitable container for my algorithm is double linked list. No such thing in 
python std lib. 
From  my test, the STLport's insertion performance of large size vector is 
better than others.

Original comment by jason.mi...@gmail.com on 1 Jul 2010 at 5:42

[GoogleCodeExporter]

My algorithm involves many insertion operation for LIST. You know, LIST is 
implemented in python in array/vector, O(n) for non-tail insertion. The best 
suitable container for my algorithm is double linked list. No such thing in 
python std lib. 
From  my test, the STLport's insertion performance of large size vector is 
better than others.

Original comment by jason.mi...@gmail.com on 1 Jul 2010 at 5:46

[GoogleCodeExporter]

can't you build your own little container, or use object attributes to maintain 
an implicit list? (e.g., x.prev = y, x.next= z) I guess you could win a lot 
more with a faster datastructure than by using another STL implementation.. 

have you profiled the result of shedskin? I can heartily recommend using 
gprof2dot.

Original comment by mark.duf...@gmail.com on 1 Jul 2010 at 2:24

[GoogleCodeExporter]

Yes, you are right. Seems like I  need to write a link list by myself.  I'm 
confused, why not python provide link list like container? :-)

Original comment by jason.mi...@gmail.com on 2 Jul 2010 at 4:54

[GoogleCodeExporter]

how exactly do you use the list? have you considered using a queue, dict, or 
heapq..?

perhaps a linked list it's just not generally useful enough, with all these 
powerful other datastructures at your fingertips. or it's generally elegant 
enough to just add 'prev/next' attributes to some simple Node class.

I see a lot of algorithmic code in python, but I don't remember the last time I 
saw an actual linked list.. thinking about it, is also _feels_ a bit low-level, 
perhaps even unpythonic, but that's just my gut feeling..

Original comment by mark.duf...@gmail.com on 2 Jul 2010 at 9:16

[GoogleCodeExporter]

found some words about this from the BDFL:

http://mail.python.org/pipermail/python-dev/2005-December/058767.html

Original comment by mark.duf...@gmail.com on 2 Jul 2010 at 9:29

[GoogleCodeExporter]

My algorithm: scan a list and pop an element according to a criteria(can be any 
position)  and put it to the end of the list.
I tried deque, worse than list.

Some guy wrote a linked list container, seems not easy to write a lib-quality 
code:
http://stackoverflow.com/questions/2154946/python-linked-list-o1-insert-remove

Thanks

Original comment by jason.mi...@gmail.com on 2 Jul 2010 at 10:13

[GoogleCodeExporter]

perhaps the heapq module (also supported by shedskin) is useful here? it keeps 
an array sorted according to some criterion, while you can push and pop items 
quickly. that way, you might even avoid the scanning, and just take the first 
element.. not sure though if you can use it here. it would be easier if I could 
see the code.. :P

Original comment by mark.duf...@gmail.com on 2 Jul 2010 at 11:56

[GoogleCodeExporter]

heapq can't help.
Actually, this list contain all active threads, and need to update state of all 
threads every cycle in the simulator. In each scan select the first  ready 
thread to execute and then put it to the end of the list to achieve Fair/RR 
scheduling policy. (need do scanning/remove/insertion millions of times)
So linked list based container is the best choice.
Currently, the list size is below 100, so using the normal list don't hurt very 
much. After the whole system is close to complete, I'll do through performance 
tuning.

Thanks  :)

Original comment by jason.mi...@gmail.com on 2 Jul 2010 at 12:39