World: r3wp
[RAMBO] The REBOL bug and enhancement database
older newer | first last |
Anton 12-Jun-2006 [1742] | I don't think so. |
Henrik 12-Jun-2006 [1743] | I wonder what happened to the AltME Bug Tracker. I thought it was way cooler than RAMBO. |
DideC 12-Jun-2006 [1744] | It was used in the Old View 1.3 project world 2 years ago. All its content was put in RAMBO when RAMBO was up and running. |
Rebolek 13-Jun-2006 [1745] | I've just found 'request-download function and it seems to me it's buggy. Can anybody confirm this? >> request-download http://rebol.com connecting to: rebol.com ** Script Error: Cannot use insert on this type port ** Where: read-thru ** Near: write/binary file data if all |
Anton 13-Jun-2006 [1746x2] | request-download - where did you find it ? |
Oh I see. :) | |
Rebolek 13-Jun-2006 [1748] | I was looking for some request function and found this one. There are more non-functional functions in REBOL AFAIK. >> link-relative-path %./ ** Script Error: link-root has no value ** Where: link-relative-path ** Near: either f: find/match file link-root |
Anton 13-Jun-2006 [1749x3] | That's obviously used in Rebol/Link. A quick helper function. Maybe it's not supposed to be exposed. |
Are you aware of my batch-download function ? | |
The request-download bug above I think is caused because file is actually a directory. So, the port type is 'directory and so the insert fails. | |
Gabriele 13-Jun-2006 [1752] | request-download usually works fine, you just need to provide a file. it downloads to the cache by default. |
Anton 13-Jun-2006 [1753] | A better error message can be thrown in read-thru by detecting the url without a file component. |
Rebolek 13-Jun-2006 [1754x2] | yes, because read http://rebol.comworks ok, so i think reqeuset-download http://rebol.comshould too |
Anton: I know about your batch download, I was just looking for some other request function | |
Anton 13-Jun-2006 [1756] | possibly mine also suffers the same problem. |
Rebolek 13-Jun-2006 [1757] | ah :) |
Anton 13-Jun-2006 [1758x5] | Actually, no it doesn't cause an error. It doesn't download anything though. |
The request-download bug is a bug in read-thru. Fix the bug in read-thru and you fix the bug in request-download. | |
>> read-thru http://rebol.com connecting to: rebol.com ** Script Error: Cannot use insert on this type port ** Where: read-thru ** Near: write/binary file data if all | |
If the directory doesn't exist in the cache, it creates it, then throws an error. If you try again, the directory already exists and there is no error, but of course still nothing is downloaded. | |
I think the wisest thing to do when given a url without a file component is throw an appropriate error. I don't advise downloading anything because we don't know how the webserver is mapping the url to its filesystem (if it is in fact doing that.) | |
Henrik 5-Jul-2006 [1763x2] | view layout [box 10x50 effect [draw [pen black white line-width 1 line 1x1 1x50 line-pattern 5 5]]] This line crashes Rebol/View 1.3.2 reliably under WinXP |
at least it does for me. can anyone confirm? | |
DideC 5-Jul-2006 [1765] | confirmed |
Anton 5-Jul-2006 [1766x2] | Yep, me too. |
(crashes without line-width too) | |
Henrik 5-Jul-2006 [1768x5] | it seems to happen if you are specifying the pen attributes and you accidentally include something else, like a drawing command, but the drawing command has to be somewhat complete to trigger the bug. interestingly, setting the box size to 0x0 does not trigger the bug, maybe because the draw block is not performed when the box is 0x0. |
it seems also to be only when specifying two colors after pen. I've boiled it down to this: view make face [size: 1x1 effect: [draw [pen black white box 0x0 0x0 line-width]]] | |
You can even remove line-width, so: view make face [size: 1x1 effect: [draw [pen black white box 0x0 0x0]]] | |
oh... I already see it in RAMBO as #4086 :-) | |
won't waste more time on it then | |
Anton 6-Jul-2006 [1773] | ok :) |
Volker 23-Sep-2006 [1774] | ; mold/all/flat broken on my ubuntu. Other systems too? o: context [a: 1] probe mold/all o probe mold/flat o print "pre-crash" probe mold/all/flat o print "survived" |
Anton 23-Sep-2006 [1775] | ; WindowsXP >> mold/all/flat o == "#[object! [^/a: 1^/]]" |
Volker 23-Sep-2006 [1776] | Looks good there. Any other linuxes? |
Ladislav 29-Sep-2006 [1777] | what do you think about #4085, are there many users that agree with this POV? |
Henrik 29-Sep-2006 [1778] | well, I sort of agree on that. While I haven't found any problems getting a decimal! returned, the datatype for the result is changed. There will always be overhead, if you are changing the datatype. I suppose it would be rather confusing to have: >> divide 1 2 == 0 and having to remember to present one of the values as decimal >> divide 1 2.0 == 0.5 maybe an 'intdivide could be provided? |
Ladislav 29-Sep-2006 [1779] | I see some inconsistencies when checking integer arithmetic: 1) DIVIDE automatically yields DECIMAL! when the exact integer result doesn't exist 2) ADD and SUBTRACT cause overflow 3) ABS "wraps over" as in: abs -2147483648 ; == -2147483648 4) REMAINDER caused crash (see #3956), I am observing that the View I am using now still crashes (?) |
Gregg 29-Sep-2006 [1780x2] | I don't agree with #4085. REBOL gives human friendly responses. There are times where I wouldn't mind having an integer division *alternative*, but I've gotten along without it so far, and the performance concern is hardly a high priority IMO. |
Edge cases are very important, but don't affect very many scripts. | |
Ladislav 29-Sep-2006 [1782] | does -2147483648 // -1 crash for you now? |
Gregg 29-Sep-2006 [1783] | Yes. |
Henrik 29-Sep-2006 [1784x2] | I get 0 under OSX |
no crash | |
Ladislav 29-Sep-2006 [1786] | that may be caused by the fact that the OSX uses different C compiler |
Gregg 29-Sep-2006 [1787] | #4149 - Pre AGG, line-pattern had problems. I submitted feedback on it long ago, but never needed it badly enough to pester RT about it. |
BrianH 29-Sep-2006 [1788x4] | Ladislav, while it nice to see APPLY being put on the front burner (RAMBO 3575), I have a problem with Carl's proposal. His examples clearly do not evaluate their function argument (like HELP or SOURCE), but this would prevent using APPLY with anonymous functions. It would be preferable to require the function to be specified with a get-word like this: f: func [a b] [a + b] a: [1 2] apply :f a |
For that matter, how would Carl's APPLY handle refinements? Using the positional arguments like the rebcode APPLY opcode? | |
I actually read #3575 before making the #4106 proposal you dismissed - that's why #4106 covered those cases in the proposal. | |
The mapcar extension seems cool though. | |
older newer | first last |