Oh, never mind your mix ups... they will pale to mines today.
I promise this is my last email today.
Jussi
2011/10/12 Benoît Minisini
> >
> > Never mind, I was trying to read source code to understand what is going
> > on, but I think I'm too tired to concentrate enough.
> >
> > This is what
Hmmm... OK so the change would be then:
static int find_string(CARRAY *_object, int mode, const char *value, int
len_value, int start)
Still I think I'll give up this for today.
Jussi
On Wed, Oct 12, 2011 at 22:55, John Spikowski wrote:
> On Wed, 2011-10-12 at 21:42 +0200, Benoît Minis
>
> Never mind, I was trying to read source code to understand what is going
> on, but I think I'm too tired to concentrate enough.
>
> This is what I read:
>
> *r4153 | gambas | 2011-09-26 04:46:48 +0300 (Mon, 26 Sep 2011) | 12 lines
>
> [INTERPRETER]
> * OPT: Optimization of locale-aware stri
> Now I'm confused.
> > I read this "Collection keys are now hashed with their eight last
> > characters." from change log,
>
> "Collection keys are now hashed with their eight last characters." is not
> the
> same sentence as "Collection keys are now limited to eight characters.", is
> it?
>
I in
On Wed, 2011-10-12 at 21:42 +0200, Benoît Minisini wrote:
> >
> > Now I'm confused.
> > I read this "Collection keys are now hashed with their eight last
> > characters." from change log,
>
> "Collection keys are now hashed with their eight last characters." is not the
> same sentence as "Collec
>
> Now I'm confused.
> I read this "Collection keys are now hashed with their eight last
> characters." from change log,
"Collection keys are now hashed with their eight last characters." is not the
same sentence as "Collection keys are now limited to eight characters.", is
it?
> and I teste
And the other way around...as you also talked about "the last 8
characters"...
DIM coll AS NEW Collection
DIM value AS String
coll.Add("A", "A12345678")
coll.Add("B", "B12345678")
coll.Add("C", "C12345678")
coll.Add("D", "12345678")
FOR EACH value IN coll
PRINT "Value: " & value &
DIM coll AS NEW Collection
DIM value AS String
coll.Add("A", "12345678A")
coll.Add("B", "12345678B")
coll.Add("C", "12345678C")
coll.Add("D", "12345678")
FOR EACH value IN coll
PRINT "Value: " & value & " Key: " & coll.key & " Value of
coll[" & coll.key & "] : " & coll[coll.ke
> Benoit is doing his theater lessons three weeks a month...
>
OK, good for Benoit.
And I don't understand what all these mails are talking about exactly. There
> is no limit at all on collection key lengths.
>
> Only the key hash functions take into account the last eight characters of
> the
>
> ulong? Where are the words of wisdom from Benoit?
>
> Jussi
>
Benoit is doing his theater lessons three weeks a month...
And I don't understand what all these mails are talking about exactly. There
is no limit at all on collection key lengths.
Only the key hash functions take into account t
On Wed, 2011-10-12 at 21:55 +0300, Jussi Lahtinen wrote:
> Yes, but it have to use different hash function, which is probably slower
> (it creates longer hash codes).
>
> Jussi
>
This is routine comes from page 436 of the dragon book.
The dragon book:
Aho-Sethi-Ulman : Compilers Principles, tec
Yes, but it have to use different hash function, which is probably slower
(it creates longer hash codes).
Jussi
On Wed, Oct 12, 2011 at 21:51, John Spikowski wrote:
> On Wed, 2011-10-12 at 21:47 +0300, Jussi Lahtinen wrote:
> > Collections are probably much slower with ScriptBasic.
> >
> > Jus
On Wed, 2011-10-12 at 21:47 +0300, Jussi Lahtinen wrote:
> Collections are probably much slower with ScriptBasic.
>
> Jussi
I doubt it. The hash extension module is written in C as a shared
object. (.so)
--
All the dat
ulong? Where are the words of wisdom from Benoit?
Jussi
On Wed, Oct 12, 2011 at 21:46, Jussi Lahtinen wrote:
> Look at gb_hash_temp.h, seems to be that limitation comes from uint.
> That may be hard to go around without performance penalty.
>
> Jussi
>
>
>
>
> On Wed, Oct 12, 2011 at 21:31, Ju
Collections are probably much slower with ScriptBasic.
Jussi
On Wed, Oct 12, 2011 at 21:45, John Spikowski wrote:
> On Wed, 2011-10-12 at 21:31 +0300, Jussi Lahtinen wrote:
> > You did it wrong.
> > Gambas would interpret your keys this way:
> > "A1234567"
> > "B1234567"
> > "C1234567"
> >
> >
Look at gb_hash_temp.h, seems to be that limitation comes from uint.
That may be hard to go around without performance penalty.
Jussi
On Wed, Oct 12, 2011 at 21:31, Jussi Lahtinen wrote:
> You did it wrong.
> Gambas would interpret your keys this way:
> "A1234567"
> "B1234567"
> "C1234567"
>
>
On Wed, 2011-10-12 at 21:31 +0300, Jussi Lahtinen wrote:
> You did it wrong.
> Gambas would interpret your keys this way:
> "A1234567"
> "B1234567"
> "C1234567"
>
> Use reversed order, that way following keys are all same:
> "12345678A"
> "12345678B"
> "12345678C"
>
> ---> "12345678"
>
> Jussi
You did it wrong.
Gambas would interpret your keys this way:
"A1234567"
"B1234567"
"C1234567"
Use reversed order, that way following keys are all same:
"12345678A"
"12345678B"
"12345678C"
---> "12345678"
Jussi
On Wed, Oct 12, 2011 at 20:16, tobias wrote:
> On 12.10.2011 19:05, John Spikow
On 12.10.2011 19:05, John Spikowski wrote:
> On Wed, 2011-10-12 at 19:43 +0300, Jussi Lahtinen wrote:
>> My first thought too... and I wonder why there is limit anyway..?
>> I have understand that collection works with hash values, and at least there
>> are no practical limitations with MD5 hash fu
On Wed, 2011-10-12 at 19:43 +0300, Jussi Lahtinen wrote:
> My first thought too... and I wonder why there is limit anyway..?
> I have understand that collection works with hash values, and at least there
> are no practical limitations with MD5 hash function.
>
> Jussi
For grins, I thought I would
My first thought too... and I wonder why there is limit anyway..?
I have understand that collection works with hash values, and at least there
are no practical limitations with MD5 hash function.
Jussi
On Wed, Oct 12, 2011 at 18:56, tobias wrote:
> On 12.10.2011 17:14, Jussi Lahtinen wrote:
>
On 12.10.2011 17:14, Jussi Lahtinen wrote:
> Documentation doesn't mention limit of key length!
> http://gambasdoc.org/help/comp/gb/collection?view
>
> Maybe there should be error or warning if key length is over 8 characters..?
wow, there really is a keylength and that small?
i wonder if i really
Documentation doesn't mention limit of key length!
http://gambasdoc.org/help/comp/gb/collection?view
Maybe there should be error or warning if key length is over 8 characters..?
Jussi
--
All the data continuously generat
Message,
Project141: symbol lookup error: /usr/lib/x86_64-linux-gnu/libstdc
++.so.6: undefined symbol: _ZNSt14error_categoryD2Ev, version
GLIBCXX_3.4.15
Steps to reproduce.
1) open project
2) run project
3) close running window
4) get the message
Also i get "The program return value 127"
I us
24 matches
Mail list logo
