World: r3wp
[Core] Discuss core issues
older newer | first last |
Henrik 25-Apr-2008 [10271x2] | not sure I understand why that is so |
well, it is none here in my tests. rather useless, I think. | |
BrianH 25-Apr-2008 [10273] | When you are running the REBOL interpreter straight, you are not running a script, so it is none. This can be useful to know. |
Henrik 25-Apr-2008 [10274x3] | by straight, you mean, I'm typing system/options/script in the console? because that's not what I'm doing. I'm running a script that probes that path and it returns none. |
or do you mean, it returns none, when you say "do %script.r" ? | |
rather than "rebol -qs script.r"? | |
BrianH 25-Apr-2008 [10277x2] | Yes. |
You probably want to be looking at system/script instead. | |
Henrik 25-Apr-2008 [10279x2] | system/script doesn't tell the name of the script. |
I had hoped to be at any time able to identify the running script by filename | |
BrianH 25-Apr-2008 [10281] | I believe that is what the file: header field is for. |
Henrik 25-Apr-2008 [10282x2] | the trouble is that the header information may not be correct |
and File: also says none | |
BrianH 25-Apr-2008 [10284x2] | You set the File: header in the script. For that matter, since the check of the script settings is specific to the currently running script, you have to add them to the script anyways, so why not correct the header while you're at it? |
Another interesting one is the Content: header. Try this script: REBOL [content: true] print mold system/script | |
Henrik 25-Apr-2008 [10286x2] | still returns none. |
but my issue is that I have over 100 scripts for this project. there might be an error in one of them, if I forget changing the header when cloning a script. If it really is impossible for rebol to determine the script name (which I highly doubt), then so be it, but it's inconvenient not to have the script name available at all times. | |
BrianH 25-Apr-2008 [10288x3] | I said Content: would be interesting, not that it would solve your problem. |
It is currently impossible to determine the filename of an inner script unless you have stored this information somewhere. For that matter, if there is an error in a script, you would only be able to get the name of the running script. If the error is in a function created by a script that is used after the script is finished executing, there is no way to determine which script the function came from without storing that information somewhere ahead of time. | |
The value system/options/script refers to the script the interpreter was started from, if any. | |
Henrik 25-Apr-2008 [10291x2] | I see the issue, but I'm not sure it's unsolvable. It seems strange to me that you can't pass a script to DO as an argument, and then not have that filename stored somewhere. If multiple scripts are DO'ed or LAUNCH'ed under that script, then append them to a block until the script is finished and then remove it again, when that script is done. system/script/parent provides similar functionality, except, it does nothing to track the true filename, but only the header which may hold incorrect information. |
I think it would be worth tracking the filename in R3. Don't want to mess up R2, if it is a big problem to implement here. | |
BrianH 25-Apr-2008 [10293x2] | It's system/script/header that stores the header of a script - parent stores the system/script object of the calling script. |
Seriously though, it should be simple to just write a loop that flags all scripts in a directory that have missing or incorrect File: headers. | |
Henrik 25-Apr-2008 [10295] | yeah and run that every time a script is renamed and perhaps also when an enduser gets a hold of the script. nope, it's too errorprone. I can see this won't be fixed, but I still think it's a missing feature. gotta go spend a couple of hours fixing this. :-) |
BrianH 25-Apr-2008 [10296] | For that matter, the mapping of bugs to scripts is not an easy task if you are using library scripts. If you are just doing scripts for effect, system/script would make sense. If you are doing scripts to load functions that will be run later, the script file name would map to the name of the script that is running when the function is run, rather than the script that was curent when it was being created. |
[unknown: 5] 27-Apr-2008 [10297] | If I have a block of datatype shouldn't I be able to do?: find blk datatype! |
BrianH 27-Apr-2008 [10298] | Yes, you can do that: >> find [a 1 3.0] decimal! == [3.0] >> find [a 1 3.0] integer! == [1 3.0] >> find [a 1 3.0] word! == [a 1 3.0] |
[unknown: 5] 27-Apr-2008 [10299] | yeah I know that but not datatype! |
BrianH 27-Apr-2008 [10300] | Oh wait, I didn't get your question |
[unknown: 5] 27-Apr-2008 [10301] | in other words what if the blk has the following: blk: [string! 2 4 5 6 integer! 7 8 9 decimal!] |
BrianH 27-Apr-2008 [10302] | After checking, I got this: >> find [1 integer!] datatype! == none ; This is right >> find reduce [1 integer!] datatype! == none ; This shouldn't happen |
[unknown: 5] 27-Apr-2008 [10303x2] | Yeah that is the problem I see. |
I would think we would want to be able to find out if a block contains a datatype given that we might not know what the datatype is if it is populated dynamically. | |
BrianH 27-Apr-2008 [10305] | The parse equivalent doesn't work either: >> parse reduce [1 integer!] [to datatype! x:] x ** Script Error: x has no value ** Where: halt-view ** Near: x |
[unknown: 5] 27-Apr-2008 [10306] | Yeah I know I ran into that problem already as well. |
BrianH 27-Apr-2008 [10307] | I haven't seen anyone put actual datatypes into blocks before; normally people just put the datatype words in as keywords. I wonder if this bug is the reason why. |
[unknown: 5] 27-Apr-2008 [10308x2] | Could be. I use it in TRETBASE |
I use it in TRETBASE to define the datatype of each respective field. It saves time and performance cost. | |
BrianH 27-Apr-2008 [10310] | Perhaps you could use the datatype words as keywords instead. |
[unknown: 5] 27-Apr-2008 [10311] | I had it that way previously. Now in my last release I do a save/all to serialize though and this has been a big boost for TRETBASE. I really don't need the find blk datatype! feature at this point but just pointing it out. |
BrianH 27-Apr-2008 [10312] | Good catch. |
[unknown: 5] 27-Apr-2008 [10313] | Thanks Brian. Just wanted to post it and see if it wasn't by design. |
BrianH 27-Apr-2008 [10314] | Fortunately the words can be converted to datatypes and back pretty easily. >> type? to datatype! to word! integer! == datatype! |
[unknown: 5] 27-Apr-2008 [10315] | I'll submit it to Rambo as a bug even though I'm not sure it is one. It just may be that nobody was thinking of doing such. |
BrianH 27-Apr-2008 [10316] | If it were by design, I can see what the benefit would be. Datatypes and their words can be easy to get mixed up. If you make it harder to store datatypes in blocks and such, people would eventually avoid such behavior. It's similar to the way that lit-words are word-active, converting to words implicitly, as Fork found out. |
[unknown: 5] 27-Apr-2008 [10317] | I'm sure the applications that would use such scenarios are few so I don't think the lack of that capability is a high priority by any means. |
BrianH 27-Apr-2008 [10318] | These self-evaluating values can be tricky sometimes. Many get tripped up by the datatype words, none, true and false. :( |
[unknown: 5] 27-Apr-2008 [10319] | I agree. |
Robert 28-Apr-2008 [10320] | What's the best and safest way to execute a block of code in a function context? Example: exec: func [code-to-execute][ a: 1 b: 1 do code-to-execute ] exec [print a + b] |
older newer | first last |