Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Limiting Serie sizes (native!)

 [1/11] from: Rebolinth::nodep::dds::nl at: 13-Aug-2003 17:09


Hello All, I was wondereing..perhpas wandering too... Is "Limiting Series" perhpas a good idea for an option inside rebol ? Example: a normal i.e. block has NO endling (yes the memory limit?) a limited block would have a limit of i.e. max 3 entries Like -> a: copy [] or a: copy/limit [] 3 {which would create a series but with a static maximum size ! If the size exceeds i.e. with append or insert or whatever then NONE / ERROR is returned.} Is this featurable or more a de-feature for rebol ? (R)egards, Norman. -- Conversation/lunch: "How do you Eat your Rebol in the Morning?"

 [2/11] from: maximo:meteorstudios at: 13-Aug-2003 11:41


If it where added it would have to be something off by default... also, It'd have to be appended as a refinament in all series based functions (like the /open refinement). and setting /limit to none would allow the block to grow once more... BUT you can already easily clip length after
> list: [1 2 3 4 5 6 7 8 9 0] > head clear at list 4
== [1 2 3] maybe this function helps in what you want to acheive? clipped-append: function [series data maxlen][][ return all [((length? series) < maxlen ) (append series data)] ; or call throw if you want an error ] -max ----------- meteor Studios, T.D. ----------- Never Argue with an idiot. They will bring you down to their level and beat you with experience

 [3/11] from: Rebolinth:nodep:dds:nl at: 13-Aug-2003 18:02


Quoting Maxim Olivier-Adlhoch Hello Maxim, Yes im using something like that right now, but My idea behind was more like: * Protecting runaway code - Wrong functions can fillup block cq. memory in milliseconds * Limiting the code in the begining in the header ie. REBOL [ blocks/limit 65535 ] * Controlling static ends, that saves extra functions for controlling serie lengths. * Perhpas dynamicly extending/descreasing the limit during serie use? But on the other hand I can emagine the structure of rebol to suffer under this enhancement too, its not dynamic anymore, BUT if you could control memory size by limiting serie sizes?? I think the idea above could be a contradiction on the idea Carl has about the dynamic behaviour of rebol ;-) (R)egards, Norman. -> -> If it where added it would have to be something off by default... -> -> also, It'd have to be appended as a refinament in all series based -> functions (like the /open refinement). -> -> and setting /limit to none would allow the block to grow once more... -> -> -> BUT you can already easily clip length after -> -> > list: [1 2 3 4 5 6 7 8 9 0] -> > head clear at list 4 -> == [1 2 3] -> -> maybe this function helps in what you want to acheive? -> -> clipped-append: function [series data maxlen][][ -> return all [((length? series) < maxlen ) (append series data)] ; or call -> throw if you want an error ->

 [4/11] from: greggirwin:mindspring at: 13-Aug-2003 20:11


Hi Norman, R> Is "Limiting Series" perhpas a good idea for an option inside rebol ? While I can see a good argument for it, I think it might require a fundamental change to some internal structures and, for that reason, probably isn't worth it given that you could work implement a solution yourself. Maybe not a transparent/optimal one, but something is better than nothing. :) -- Gregg

 [5/11] from: carl:rebol at: 13-Aug-2003 19:16


It turns out that REBOL does limit series expansion to protect itself internally, although not to the granular level that you suggest. (Two weeks ago, I hit the limit for the first time ever with REBOL on one of our net servers. It was loading a 500MB file on a regular basis (spam filter data file). The LOAD happened so quickly that I had no idea the file was that large.) It would be possible for there to be a way to limit a series on a per series basis, although it is interesting to think about the methods of such a function -- in other words, you have to have a way to set, get, and change the limits on a per series basis -- sort of like set-modes does for ports. An example might be: set-modes series [limit: 10000] Of course, if we did that, then you might also want other controls for blocks, like: set-modes block [newlines: false] which would remove the hidden newline markers from blocks (ie. what happens on MOLDed LOADed blocks). Am I right? -Carl

 [6/11] from: nitsch-lists:netcologne at: 14-Aug-2003 15:03


Rebolinth wrote:
>Hello All, >I was wondereing..perhpas wandering too...
<<quoted lines omitted: 8>>
>{which would create a series but with a static maximum size ! >If the size exceeds i.e. with append or insert or whatever then NONE /
ERROR
>is returned.} > >Is this featurable or more a de-feature for rebol ? >
Pretty much no-feature IMHO. You want to restrict complete memory-usage, not size of a single block. On linux /etc/profile:ulimit -v 396000 #jdk1.4+mozilla #something -v 640000 on a 640mb-machine IMHO ulimit inbuild could make sense, as well as time-restrictions, because scripts can terminate cleaner. throwing a heavy transaction away instead of writing to half the files and then hard-crash. but yu have to address machine-capacities, limits should be different for 128MB or 640MB-machine. Also specially mold could use limits, so molding system stops after some mb. -Volker

 [7/11] from: maximo:meteorstudios at: 14-Aug-2003 8:59


> set-modes block [newlines: false] > > which would remove the hidden newline markers from blocks > (ie. what happens > on MOLDed LOADed blocks).
speaking of which would it be possible to control these hidden markers ourselves like an insert ? when writting data files, I find very usefull to have proper block indentation (somewhat like looking at an xml data sheet). If could add them manually , I would not have to run my iblock function just after a save... this function reads the data file as text and adds newlines where blocks start and end, but its dangerous cause a string with square brackets {[} gets quite hard to handle. MAx

 [8/11] from: nitsch-lists:netcologne at: 14-Aug-2003 16:06


[carl--rebol--com] wrote:
>It turns out that REBOL does limit series expansion to protect itself internally, >although not to the granular level that you suggest.
<<quoted lines omitted: 7>>
>An example might be: > set-modes series [limit: 10000]
array [2 2 2 2 2 ..] or with the load, its (length? messages) * (medium-message-length). hard to balance IMHO. Eventually some restriction to newly allocated memory? add-only-mb 4 [load %spam.r]
> >Of course, if we did that, then you might also want other controls for blocks, >like: > > set-modes block [newlines: false] > >which would remove the hidden newline markers from blocks (ie. what happens >on MOLDed LOADed blocks). > >Am I right? >
Well, i would be very happy about a [newlines: true]. because typical software is very surprised about molds 1MB-lines. including open/lines in old versions. lots of very short lines are at least loadable in such editors. Really very happy i would be if i can set newlines-markers individually. because of data: [ name "me" id 1 name "you" id 2 ] ;= [ ;= name "me" id 1 ;= name "you" id 2 ;= ] head change/part skip data 4 [name "you" id "3"] 4 ;= [ ;= name "me" id 1 name "you" id "3" ;= ] formatting broken. mark-newline skip data 4 would help? But Holger said that makes no sense IIRC, something like wrapping would be preferable. Maybe i explained cryptic again?

 [9/11] from: greggirwin:mindspring at: 14-Aug-2003 8:45


Hi Carl, crc> It would be possible for there to be a way to limit a series on a per series crc> basis, although it is interesting to think about the methods of such a function -- crc> in other words, you have to have a way to set, get, and change the limits on crc> a per series basis -- sort of like set-modes does for ports. Give your newlines example, I can see this is something requiring careful consideration. There are times where I'd like easy control over molded or saved formats (e.g. MOLD produces a nice format for object spec blocks, but then you have to strip the "make object!" part if you only want the block), but it's not a killer issue. Once you have modes available for blocks, then do you need to offer a way to set defaults, so all blocks in your app can use a particular set of modes without having to set them individually? What other modes might there be and how would they simplify our lives or let us do things we can't do now? Those would be my questions. -- Gregg

 [10/11] from: amicom:sonic at: 14-Aug-2003 19:19


At 08:45 AM 8/14/03 -0600, you wrote:
>Give your newlines example, I can see this is something requiring >careful consideration. There are times where I'd like easy control >over molded or saved formats (e.g. MOLD produces a nice format for >object spec blocks, but then you have to strip the "make object!" part >if you only want the block), but it's not a killer issue.
If you don't want the "make object!" part, try this:
>> print mold third system/user
[name: "Bo" email: none home: none words: none]

 [11/11] from: greggirwin:mindspring at: 14-Aug-2003 22:56


Hi Bo, BoRL> If you don't want the "make object!" part, try this: BoRL> >> print mold third system/user BoRL> [name: "Bo" email: none home: none words: none] Ah, but that defeats the purpose as it molds without the newlines between elements. -- Gregg

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted