World: r3wp
[RAMBO] The REBOL bug and enhancement database
| older newer | first last |
| Volker 28-Jan-2006 [1521] | but the call to expand-packet happens only if there is extra data. if i outcomment "if not zero? num [" it works |
| Gabriele 29-Jan-2006 [1522] | Volker, interesting finding, i will look into it. i guess that removing that if is the correct fix. |
| Ladislav 2-Feb-2006 [1523] | added a new 1.3.2 bug to Rambo: b: head insert copy [] make list! [1] produces an invalid block |
| Graham 5-Feb-2006 [1524x2] | RAMBO Ticket #-578 Exists? corrupts http protocol. |
Are Rambo tickets now negative ?? | |
| Sunanda 5-Feb-2006 [1526] | I believe the new/unreviewed submissions have a temporary sequence number and it is negative. Once the submission been checked manually and found not to be spam, it'll get a more permanent sequence number. |
| Graham 5-Feb-2006 [1527x3] | >> q: query http://www.rebol.com/index.html == none >> read http://www.rebol.com/ == {<html> <head> <META NAME="Description" CONTENT="Lightweight distributed computing, collaboration, and programming systems for t... >> q: query http://www.rebol.com/asdfsa.r ** User Error: Error. Target url: http://www.rebol.com/asdfsa.r could not be retrieved. Server response: HTTP/1.0 404 Not Found ** Near: q: query http://www.rebol.com/asdfsa.r >> read http://www.rebol.com/ == "" |
looks like 'query is corrupting http protocol. | |
*but* also fixes it :) >> q: query http://www.rebol.com/index.html == none >> read http://www.rebol.com/ == {<html> <head> <META NAME="Description" CONTENT="Lightweight distributed computing, collaboration, and programming systems for t... | |
| Anton 6-Feb-2006 [1530x6] | Nice one Graham. |
This looks like an inconsistency: >> save %afile [[1]] >> load/all %afile == [[[1]] ] >> save %afile [[1] 2] >> load/all %afile == [[1] 2 ] >> save %afile [[1] 2 3] >> load/all %afile == [[1] 2 3 ]] | |
The first load/all seems to wrap in brackets once too often ! | |
The difference is in whether there is a single item or multiple items being loaded. | |
Mmm, don't see it in RAMBO already. Anybody can confirm ? By the way, SAVE or SAVE/ALL doesn't make a difference, but it must be LOAD/ALL to show the inconsistency. | |
I'm sure we've been over this one before, actually. Similar behaviour: >> save %afile [1] >> load/all %afile == [[1] ] >> save %afile [1 2] >> load/all %afile == [1 2 ] >> save %afile [1 2 3] >> load/all %afile == [1 2 3 ] | |
| Gabriele 6-Feb-2006 [1536x2] | that's because save is like mold/only, except when the block only has one item. |
i'm not sure we can classify it as a bug. | |
| Anton 7-Feb-2006 [1538] | It's difficult to know what was saved after the fact. Or at least, I am finding it difficult to see the logic clearly, in order to produce a nice loading function that handles all cases consistently. |
| Gabriele 7-Feb-2006 [1539x2] | either use write mold/only, or don't use load/all. |
though, i guess this deserves some more thinking. add it as an issue ticket? or as note... | |
| Anton 7-Feb-2006 [1541x10] | Ahh.. Of course ! Excellent suggestion. |
Last time I remember Carl talking about it, he seemed to like the idea of being able to save/load a single value easily, so it is perhaps difficult to convince him. | |
.. to change it. | |
My solution: I used SAVE and SAVE/ALL, and LOAD. The reason I wanted to use SAVE/ALL is to save none! in a serialised way. So I used SAVE/ALL in one place for that, and in another place I used SAVE and just made sure I wasn't saving none values, so it wasn't a problem. | |
(I will keep a note to use write mold/only, in case any problems crop up.) | |
Hang on a minute. There is an issue there, surely: | |
>> save %afile [1] >> print read %afile [1] >> load %afile == [1] >> load/all %afile == [[1] ] | |
>> save %afile [1 2] >> print read %afile 1 2 >> load %afile == [1 2 ] >> load/all %afile == [1 2 ] | |
LOAD and LOAD/ALL are the same when there are multiple values in the block, but different when there is only one value. | |
(I think I will post a ticket for this...) | |
| Gabriele 8-Feb-2006 [1551] | LOAD and LOAD/ALL are the same when there are multiple values in the block, but different when there is only one value. Exactly, and I think that is intentional, although weird and probably deserving some discussion. |
| Anton 8-Feb-2006 [1552x2] | Deserving discussion, yes. Do you have any idea what this difference of LOAD/ALL could be used for ? Anyone ? |
I suppose that's why I should post a ticket. :) | |
| Henrik 8-Feb-2006 [1554] | I first thought that mold and mold/all would be the mirrored functions of load and load/all, but that's not the case? |
| Anton 8-Feb-2006 [1555x2] | Umm... |
I would say SAVE should mirror WRITE MOLD, and LOAD should be orthogonal to that. (Or at least, that's what you kind of expect.) (and same for SAVE/ALL, MOLD/ALL, LOAD/ALL.) | |
| Henrik 8-Feb-2006 [1557] | hmm... |
| Ashley 8-Feb-2006 [1558] | load/all is very useful if you are loading a block of values from a file, eg. 1 2 3 "Bob" and you don't want to code for the case where the file only has one value in it. For example, with a file containing a single value in it I get: >> load %a.txt == 1 >> load/all %a.txt == [1] but in all other cases (zero or more than one value), I always get a block. I asked about this ages ago and the answer at the time was that beginners expected to be able to "load" a value without worrying about unwanted block creation (and those who wanted it would use load/all). |
| Anton 8-Feb-2006 [1559] | Yes, it all seemed to make sense at the time SAVE/ALL and LOAD/ALL were implemented. I remember the discussions about it. But trying to get a consistent method for saving/loading my data the other night proved very confusing. I spent a couple of hours testing different cases and I still haven't finished thinking about the issue. |
| Henrik 8-Feb-2006 [1560] | I would probably have said that if you are to return something, use as few different types as possible, even at the cost of an additional function. then a block would be returned regardless of contents |
| Anton 8-Feb-2006 [1561] | Yes, that's what I had in mind. One way of saving and loading, where I can always expect the data in a particular format. |
| Ashley 8-Feb-2006 [1562] | In RebDB I ended up with the following to handle this: switch/default length? tables/:table/data [ 0 [write tables/:table/dat-file ""] 1 [save/all tables/:table/dat-file first tables/:table/data] ][ save/all tables/:table/dat-file tables/:table/data ] |
| Anton 8-Feb-2006 [1563x3] | I think, as per Gabriele's suggestion, that can be simplified to: write tables/:table/dat-file mold/all tables/:table/data (though it's not exactly the same for the 0 case.) |
(The only reason I would want to use SAVE or SAVE/ALL is to avoid the slightly longer expression: WRITE MOLD or WRITE MOLD/ALL) | |
If I have to make a custom function to get consistent behaviour then I might as well just use WRITE. :-) | |
| Gabriele 8-Feb-2006 [1566x2] | note: save/all and load/all are unrelated, and they were added at different times. |
also, if you are using load/all, you will need mold/only/all on the example above. the /all in mold is unrelated to the /all in load and means that all values are serialized. | |
| Carl 8-Feb-2006 [1568] | Yes, I agree that the difference in behavior makes it more painful. |
| Graham 8-Feb-2006 [1569] | From the Orca channel .. it would be good to set up a way of "voting" or other way of determining of what are the priorities for *developers* that RT should focus on. |
| [unknown: 9] 8-Feb-2006 [1570] | Agreed. |
| older newer | first last |