World: r3wp
[Core] Discuss core issues
older newer | first last |
Rebolek 9-Nov-2006 [6111x2] | DEHEX |
>> dehex "alcohol %26 tobacco" == "alcohol & tobacco" | |
Graham 9-Nov-2006 [6113x2] | OH ?? I tried that too ... hmm. |
oh well....brain not working properly ! | |
Rebolek 9-Nov-2006 [6115] | Interesting, >> to lit-word! first [ < ] == '< >> to lit-word! first [<] ** Syntax Error: Invalid tag -- < ** Near: (line 1) to lit-word! first [<] |
Cyphre 9-Nov-2006 [6116] | It looks Rebol's lexical parser detects #"<" without space at the end as a tag! |
Rebolek 9-Nov-2006 [6117] | I cannot INCLUDE script with that line (to lit word! first [ < ]). 'include uses LOAD/ALL and LOAD/ALL changes the line to (to lit word! first [<]). While the first line works OK, the second one crashes. |
Cyphre 9-Nov-2006 [6118] | >> load [< ] == [<] >> load [<] ** Syntax Error: Invalid tag -- < ** Near: (line 1) load [<] >> load [<a ] ** Syntax Error: Invalid tag -- <a ** Near: (line 1) load [<a ] >> |
Rebolek 9-Nov-2006 [6119] | yes, LOAD is the cause. |
Pekr 9-Nov-2006 [6120] | it seems so ... but wouldn't we expect a block? |
Rebolek 9-Nov-2006 [6121] | I don't expect anything, I just want to set some words for parser :) |
Cyphre 9-Nov-2006 [6122] | so it looks like a bug to me. There should be added a condition where the '< is at the end of loaded block imo. |
Rebolek 9-Nov-2006 [6123x2] | you cannot parse [to '<] but you can parse [to _lt] if _lt is '< .... |
Yes, a bug probably | |
Cyphre 9-Nov-2006 [6125] | The lexical parser shoul probably check for <...> in the TAG! detection but maybe Rebol is just checking for the first '< to be faster? |
Anton 9-Nov-2006 [6126] | Ok, Rebolek and anyone else, Syntax errors should not be called "crashes". A crash is something more serious which takes down the interpreter. |
Pekr 9-Nov-2006 [6127x3] | lexical parser should give precedence to ] followed by a space, as it is a closure to initiated block, no? :-) |
(me not being parse expert at all :-) | |
I agree with Anton - for me "crash" is when something takes down rebol ... | |
Rebolek 9-Nov-2006 [6130] | Anton sorry, I'm no native speaker, I'll take more care |
Anton 9-Nov-2006 [6131] | No problem, just keeping terminology clear. |
Cyphre 9-Nov-2006 [6132] | Rebolek: please put it in RAMBO if there isn't already present. |
Rebolek 9-Nov-2006 [6133] | OK. What should be the priority to have it fixed in 1.3.3? ;) |
Pekr 9-Nov-2006 [6134x2] | red-icons = old time problem with timestamps we can't rely upon |
actually I think that bug is gonna be fixed, as solution seems to be obvious ... | |
Cyphre 9-Nov-2006 [6136] | BTW you can always use this workaround: to-lit-word "<" |
Pekr 9-Nov-2006 [6137] | other - lowering dekstop timeout - absolutly obtrusive experience trying to connect to internet, when you are behind the proxy. I would not connect by default |
Anton 9-Nov-2006 [6138x2] | Hmm.... I think "medium". It's good to also note in your bug report why it was a problem for you (the space was sucked out of the block). |
(also note the workaround you use.) | |
Rebolek 9-Nov-2006 [6140x2] | I've no workaround right now, because I've noticed it half an hour ago, but Cyphre's example looks promising. |
I'm not sure why I'm using first [ < ] instead of "<" because the second looks more logical | |
Maxim 9-Nov-2006 [6142x6] | I have a little question regarding extern library useage... |
I am supplying a string! to a function, which is supposed to be used as a buffer. | |
lets say: buf: make string! 100 | |
but when the function returns, my string is still size 0. although I know the call has worked! | |
cause If I send a string filled up with 100 spaces, I actually get some chars overwritten and a 0 char where it should... | |
so my question is basically, what is the proper/expected means of submitting a buffer ? | |
Pekr 9-Nov-2006 [6148x3] | if you submit string to your function, it sends just pointer |
so it should work correctly, expecting zero terminator in C level? | |
maybe it would be better to see your wrapper | |
Maxim 9-Nov-2006 [6151] | hum... I think I understand something... because the call, is not returning a string!, but filling up a buffer, REBOL has no means to know that it should fix the string! and resize it to the zero terminator, right? |
Graham 9-Nov-2006 [6152x2] | don't you define in your wrapper call what the function returns? |
You don't pass a string as a bit of memory to be filled ... | |
Maxim 9-Nov-2006 [6154x2] | yes it returns success, but fills up the buffer I send it... it does not return the buffer itself... |
well many C calls expect a buffer as an argument... what's the prefered method then? | |
Pekr 9-Nov-2006 [6156x2] | it would be good to see original C function spec. Because - e.g. when I was wrapping one function (trying to investigate red-icons problem IIRC), the function was clearly expecting chars (certain amount), but it did not work, untill Ladislav came in and changed it to struct for that part of function. |
I just hope, that for R3, more automatic wrapping will be possible. | |
Maxim 9-Nov-2006 [6158x3] | yeah... like .h file loading ;-) we can always dream ;-) |
my routine spec: username: make routine! [ "Get the current logon name of thread which launched REBOL" buffer [char*] count [string!] return: [integer!] ] libinfo "GetUserNameA" | |
C spec: BOOL GetUserName( LPTSTR lpBuffer, LPDWORD lpnSize ); | |
older newer | first last |