coll limits, maybe cosmetic...


    Jul 20 2006 | 1:52 pm
    I just loaded a textfile into coll which contained close to 50000 entries of prime numbers. It would display the following in the Max window:
    coll: finished, -16437 lines

    • Jul 21 2006 | 10:08 am
      Stefan Tiedje wrote: > I just loaded a textfile into coll which contained close to 50000 > entries of prime numbers. It would display the following in the Max window:
      My original emssage seemed to have been cut...
      I want to add, I just loaded 1 million lines of prime numbers into a coll and it seems to be happy, only the report of how many lines have been loaded seems to be off... (And to load a text file of several MB will take some time as well..;-) This is pretty amazing. It does slow down the computer, though I can't measure it with a timer, the visual feedback I get is maybe half a second behind when recalling...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jul 21 2006 | 11:35 am
      On 21-Jul-2006, at 12:08, Stefan Tiedje wrote: > Stefan Tiedje wrote: >> I just loaded a textfile into coll which contained close to 50000 >> entries of prime numbers. It would display the following in the >> Max window:
      coll's source code is published with older SDKs. You should be able to find the cause there.
      Ah, found it. Line 1926 in coll.c
      void coll_fromtext(t_xcoll *x, t_handle han, long size) { long onset = 0; char symout[256]; short line,aCount; ^^^^^
      At the time coll was first written, it was probably reasonable to assume that a coll file would not contain more than 32,767 lines. The issue is indeed cosmetic. However, if you have an error in the 999,999th line, the error message will be a little unhelpful.
      -- Peter
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jul 24 2006 | 7:12 pm
      Peter Castine wrote: > At the time coll was first written, it was probably reasonable to > assume that a coll file would not contain more than 32,767 lines.
      Wasn't that time not also a limit of 64k for the size of text objects? That might explain that as well...
      > The issue is indeed cosmetic. However, if you have an error in the > 999,999th line, the error message will be a little unhelpful.
      actually there is also a non-cosmetic issue, with my million lines coll the next message doesn't work. it will always put out the first element. Its not urgent though...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jul 24 2006 | 7:35 pm
      On 24 Jul 2006, at 21:12, Stefan Tiedje wrote:
      > with my million lines coll
      Oiks... Ever thought of using a database?
      nick rothwell -- composition, systems, performance -- http:// www.cassiel.com
    • Jul 25 2006 | 11:02 am
      Nick Rothwell wrote: > > On 24 Jul 2006, at 21:12, Stefan Tiedje wrote: > >> with my million lines coll > > > Oiks... Ever thought of using a database?
      As I said, its not urgent, because doing what I did is asking for trouble. I was just wondering, and having that coll just did some tests...
      I would store it into a buffer~/soundfile in this case, as there are only numbers stored and the access of a buffer with peek~ for sure is way more efficient. Just recalling the coll with a deferlowed counter would give me less than 10 hits per second, which is more than 100 ms per query... (peek is immediate...). And the soundfile is smaller than the coll file
      I am even not sure if this should be fixed at all, as these experiments show, that coll is astonishingly stable. Its not worth to "fix" something which will never be a real world problem (Never change a winning team).
      The opposite is rather true, these little annoyance will force you to go for a more solid solution (if your coll would ever grow that big)...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com