r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Maxim
23-Apr-2010
[16441]
because of liquid's lazyness, very few things are actually optimised 
(really need to)... but right now I have a problem on initialization 
where there is so much linkeage being done, it does create a nagging 
pause on startup.


I already know a few things that will greatly optimise liquid itself, 
and will implement speed minded plugs specifically for GLASS, but 
your input will be invaluable.


you've spent sooo much time on this specific aspect of REBOL coding 
that it will come naturally to you.
Steeve
23-Apr-2010
[16442]
Well, It will a pleasure :)
Optimizing scripts is my hoby
Maxim
23-Apr-2010
[16443]
in the last 6 months, I've allready optimized liquid's kernel by 
a factor of at least 50 times I think I can speed it up at least 
10x more.  on specific points, I can probably improve it even more. 
 that will probably come at increased memory use for some plugs though.
Steeve
23-Apr-2010
[16444]
Propably some inspectors could be added in the flow  to do some JIT 
compilation of your plugs ;-)
Maxim
23-Apr-2010
[16445x5]
for example, I am thinking of building a !node and !container base 
plugs which cannot mutate into different processing mechanisms.... 
will all the removed overhead, that will make a BIG difference.  


it will require a bit more experience in handling liquid... but within 
controled environments like glass and glob, this can be a non-issue.
yes.  it would be exceedingly easy, since you have state information 
about things being clean or not, and liquid is 100% class based OOP 
(as opposed to prototype) so once a node has been defined, it can 
be freely JIT, since every reference to the instance is referenced, 
not bound.
which is why it used at least 100 times less RAM than it (and is 
200 times faster) than would be under traditional REBOL object use.
with R3 I want to replace every part of the kernel with commands, 
but for that, we need access to the object! datatype within extensions 
(or host-kit).
AFAICT the next few extension release will allow some acces to context, 
so that might be the green light for me to go ahead and adapt my 
dataflow framework to R3.
Gregg
23-Apr-2010
[16450]
I wouldn't say We MUST add /SAME to FIND, though it could be useful 
in special cases. Another posssibility, though I want to think about 
it more before standing behind it, would be to allow AT to take an 
index value that is a reference. Hmmm, no, maybe not. It would then 
have to return NONE if the item wasn't in the block. Nevermind.
Steeve
23-Apr-2010
[16451]
lol
Tomc
23-Apr-2010
[16452x2]
find/at  foo bar
== NaN
revolucent
30-Apr-2010
[16454x3]
How can I check that a given value conforms to a typeset? E.g.,  
If I say "make typeset! [string! integer!]" how can I check that 
the number 17 conforms to that typeset?
I've written a recursive function to do it, but I wondered if there 
weren't some better way.
Never mind. I just issued "source any-string?" and got my answer: 
find typeset type? :value. Perfect.
Gregg
3-May-2010
[16457x2]
On MIN/MAX with pairs, sorry I wasn't clear. I do NOT think it's 
a bug. I use that behavior myself, and seem to recall it being discussed 
long ago. It may not be what you expect initially, but I think it's 
the right design choice.
I just wanted to point it out in the context of pair comparisons.
Terry
7-May-2010
[16459x2]
how does one probe a map! ?
(probably an R3 question)
Maxim
7-May-2010
[16461x2]
>> probe a
make map! [
    r 4
]
== make map! [
    r 4
]

>> foreach [key value] a [print key]
r
>> a/e: 5
== 5

>> foreach [key value] a [print key]
r
e
I just tried the most obvious and it worked.
Steeve
7-May-2010
[16463]
>>foreach key a [print key]
works too.
Terry
7-May-2010
[16464]
how about this.. adding a variable as key in a map ie:
n: make map![]
b: 4398

n/b: "42" ; where b is 4398?
Steeve
7-May-2010
[16465x3]
n/:b:
n/:b:
n/:b:
Terry
7-May-2010
[16468]
ah ;)
Steeve
7-May-2010
[16469]
oups...
Terry
7-May-2010
[16470]
hmm... need a delimeter in the key.. 
n/8497:9823 ;err invalid time
n/9384-5842; err invalid date
Steeve
7-May-2010
[16471x6]
n/123x345
... doesn't work...
you could use an integer to store the 2 values (but each one limited 
to 2^32)
>> a: 1234
== 1234
>> b: 345
== 345

>> key: b or shift a 32
== 5299989643609
or you can make a string with the 2 parts and the delimiter as a 
key, but it will cost more memory
>> m/("123-456"): 45
== 45
Terry
7-May-2010
[16477x2]
there's no end of keys .. could use zero as the delim i suppose
what would the mem cost be to use strings?
Steeve
7-May-2010
[16479]
there's theory and reality, just make some tests using dp
Terry
7-May-2010
[16480]
dp? duck pond?
Steeve
7-May-2010
[16481]
? dp
Terry
7-May-2010
[16482]
dp.. your acronym.. what does it mean?
Henrik
7-May-2010
[16483]
? dp
Steeve
7-May-2010
[16484]
it's a function of R3
Terry
7-May-2010
[16485]
is it possible to search the value of map! without looping?
Steeve
7-May-2010
[16486]
well... take that memory problem aside for the moment , and go with 
string keys :)
Terry
7-May-2010
[16487]
wow
Steeve
7-May-2010
[16488]
ouch, don't think so...
Actually maybe your real key is the value and not the key.
Terry
7-May-2010
[16489x2]
that is REALLY fast
1,000,000 GETs  in 1.387 seconds
can't use the value as the key.. it could be 1GB