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

World: r3wp

[Core] Discuss core issues

Geomol
17-Feb-2008
[9133]
Have you checked the bug database, if it's a known issue?
http://www.rebol.net/cgi-bin/rambo.r
[unknown: 5]
17-Feb-2008
[9134]
If it is the sort function then that would explain why putting the 
checks in my script didn't catch it because I was only using the 
sort in the console to test some other ideas.
Geomol
17-Feb-2008
[9135]
(Just click the link, I gave, to run the bug database in your browser.)
[unknown: 5]
17-Feb-2008
[9136]
I just searched it and didn't find mention of this problem.
Geomol
17-Feb-2008
[9137]
This is related, I think: http://www.rebol.net/cgi-bin/rambo.r?id=3761&
[unknown: 5]
17-Feb-2008
[9138x8]
Possibly.
But that one says its built already so there is still a problem that 
exists with the function.
I'm going to run another test real quick to see if it effects just 
the list datatype by converting to block before the sort
Ahhh - the problem goes away if I convert my list to a block datatype 
before the sort.
So sort is causing the problem when performed on a list datatype
Do you know of any mezzanine functions that utilize sort?
Is there a version 2.76?
2.7.6 rather
Geomol
17-Feb-2008
[9146x2]
Different versions: http://www.rebol.net/builds/031/
Sort scripts: http://www.rebol.org/cgi-bin/cgiwrap/rebol/search.r?find=sort&form=yes
[unknown: 5]
17-Feb-2008
[9148]
Yeah I don't see any hint of a version 2.7.6 in that list but I seen 
in the Rambo database a reference to one problem being fixed in version 
2.7.6.
Henrik
17-Feb-2008
[9149]
There is an internal alpha of 2.7.6 that has not been released and 
I don't think RAMBO yet shows all the bugfixes for 2.7.6. Carl doesn't 
want to spend too much time on it, so Maarten is appointed release 
manager for it, as he was with R3 alpha 1.
[unknown: 5]
17-Feb-2008
[9150]
so does this mean that 2.7.6 may never get released and instead just 
R3?
Henrik
17-Feb-2008
[9151]
I hope not :-) I need some of those fixes for R2.
[unknown: 5]
17-Feb-2008
[9152]
I don't mind the problems as long as they are being fixed for R3.
Henrik
17-Feb-2008
[9153]
I have production systems that will not be migrated to R3, so I hope 
they will be fixed.
[unknown: 5]
17-Feb-2008
[9154]
I don't know the sales stradegy for R3 which is why I'm not currently 
designing TRETBASE around it.  If I knew more I might make the leap 
now but didn't know how long alphas would be operable etc, costs 
of the end product of R3, etc...
Henrik
17-Feb-2008
[9155]
it's a dangerous period for relying on R3 stability, because of modules, 
tasks and unicode not being in place yet. some very basic things 
may still change so much that the initial R3 test scripts might not 
work anymore.
[unknown: 5]
17-Feb-2008
[9156]
Yeah good point.
Henrik
17-Feb-2008
[9157]
I wouldn't expect production stability until about a year from now, 
but that doesn't mean we don't get to play with a lot of juicy alphas 
in the mean time. :-)
[unknown: 5]
17-Feb-2008
[9158]
I actually haven't played with them much - it hasn't yet appealed 
to me.  Maybe I just don't understand everything that is changing.
Henrik
17-Feb-2008
[9159]
yeah, it can be a little hard. although a good measure is to try 
the VID3 dialect and compare that with R2 VID. what you can do there 
is basically how much R3 is beyond R2 in capability in almost all 
areas. One thing I love is how each and every single function is 
being visited for functionality enhancements that allows you to for 
example write a loop with FOREACH, that manipulates with the block 
it's traversing in a complex way in just a few lines of code. Many 
things that require 10-20 lines of code in R2 can be done in 3-5 
lines in R3.
[unknown: 5]
17-Feb-2008
[9160x2]
Wow that is pretty amazing considering that R2 is very concise already.
Sort bug has now been submitted to RAMBO.
Anton
17-Feb-2008
[9162]
I hope you reduced the report. The bug can be shown with only:
>> sort make list! [1 4 5 6]
== make list! [1 4 end sort]
[unknown: 5]
17-Feb-2008
[9163]
i probably should have but I submitted what I outputted here and 
pasted it as it was fresh on my mind.
Anton
17-Feb-2008
[9164]
Oh well, it's in there now, that's good.
[unknown: 5]
17-Feb-2008
[9165x3]
It's strange what we both get:

>> sort make list! [1 2 3 4]
== make list! [1 2 end 3]
>> sort make list! [1 4 5 6]
== make list! [1 4 end :context!]
weird I got the :context! datatype.
context! and object! are not interchangeble however.
BrianH
17-Feb-2008
[9168]
It seems like the memory manager is getting list! nodes from a common 
pool, and then SORT is messing up the rebuilding of the list and 
putting random data in the post-sorted list during the sorting process.
Gabriele
18-Feb-2008
[9169]
end! is the block end marker, you should never see that. list! is 
bugged, and noone ever used it, that's why it's not even in R3.
[unknown: 5]
18-Feb-2008
[9170]
When you say that list is buggged in what way?  I would like to know 
what to watch out for when using it.
Henrik
18-Feb-2008
[9171x2]
I thought this was actually mentioned in the docs. I read some place 
once that sorting and some other functions were never meant to be 
used with list!. I think it's in the appendix of the Core documentation 
somewhere.
perhaps it would be cleaner to simply disallow SORT to work on list! 
?
[unknown: 5]
18-Feb-2008
[9173]
Was just thinking the same thing if that is indeed the case.
james_nak
18-Feb-2008
[9174]
Thanks Anton and Graham. My bad. I started checking to see if my 
nested objects were even working (behaving as objects) after I appended 
them (and before saving them). Lo and behold they were so no wonder! 
Thanks for your time and tips.
BrianH
18-Feb-2008
[9175]
Maybe it would be a good idea to make SORT work on list! instead, 
even if it needs to be special-cased.
[unknown: 5]
18-Feb-2008
[9176x2]
;Is this a bug with list also?

>> list: to-list [1 2]
== make list! [1 2]
>> index? list
== 1
>> remove find list 1
== make list! [2]
>> index? list
** Script Error: Out of range or past end
** Where: halt-view
** Near: index? list
>>
Seem the indexing is not what I expected on that.
Henrik
18-Feb-2008
[9178]
gotta find those docs. indexing for list! is not the same as for 
block!
BrianH
18-Feb-2008
[9179]
Design difference, not bug. It's not a problem with indexing - you 
just deleted the node that 'list was referring to.
[unknown: 5]
18-Feb-2008
[9180x2]
I looked at the docs for it but it still seems like strange behavior.
Ahh I see BrianH.  Thanks.
Henrik
18-Feb-2008
[9182]
INSERT for list! behaves like APPEND for block! I think list! was 
made for appending large amounts of data using INSERT much quicker 
than block!