World: r3wp
[Core] Discuss core issues
older newer | first last |
btiffin 1-Apr-2008 [10056] | Sorry Robert; I clown. All computer related activity is fun, exciting and worthy of pursuit. But Silly beats Gooey :) |
RobertS 1-Apr-2008 [10057] | I swear, all I hiot was the 'enter' key. And Kazaam ... there was my clipboard up in public.... at least it was that Rebol VID script ... ; - ) |
Reichart 1-Apr-2008 [10058] | LOL... |
Fork 1-Apr-2008 [10059x3] | RobertS: try pastebin, it even lets you show diffs as you make new versions of a snippet! http://pastebin.com/ |
These days on IRC people who post more than 5 lines of code in a chat channel get banned. They're none too friendly about it. :) | |
Ah, ok, was an accident. Still, useful tool. :) | |
RobertS 1-Apr-2008 [10062x2] | Some Smalltalk have 'clipboards' that stack CTRL-c so you can go through your last clips ... almost replaces the history in a REPL ; - ) |
fork ... I offer rlwrap in return http://utopia.knoware.nl/~hlub/rlwrap/man.html as a wrapper for readline which I call from Smalltalk when there are PTY issues with some cmd line tool. Almost as useful as the unix screen cmd ; - ) | |
RobertS 2-Apr-2008 [10064] | rlwrap + pipes can be used to wrap even Rebol core for those who refuse to use View while waiting for a DLL/so |
Fork 2-Apr-2008 [10065x9] | Thanks Robert, I would have to see it in action to truly understand the usefulness. And on that note, here's another good tool, Jing: http://jingproject.com |
You can easily capture and share short videos of the demonstration of tools-in-action | |
Okay, new question, I will ask many... :) I am trying to write a new version of an assert macro which is able to do "location-parameterized-assertions", similar to what I describe in this article:http://hostilefork.com/2005/05/01/location-parameterized-assertions/ | |
I have gathered that I need to find a way for the caller to pass in the required information, e.g. | |
assert system/script/header length? array > 3 | |
I'd like a shorthand for this which evaluates the expression in the calling context, and I'd also like to know the line #... | |
So I'm willing to write: assert FOO length? array > 3 | |
I seek FOO: f(system/script/header) which would help me do this, and also what it would take to get the line number of this specific instance of FOO | |
It would be nice if I could somehow do this without the FOO helper... so if REBOL has some magic to reflect the call stack and pick out the necessary information that would be nice. | |
btiffin 2-Apr-2008 [10074] | REBOL is not so big on line numbers. Even when you look at http://www.rebol.net/cookbook/recipes/0042.html which is Carl's source parser, and added a line number tracker, it won't be accurate as a multiline comment (embedded newlines) counts as one source entity to LOAD. I think the best you could really hope for is an offset into the sources at the start of a entity. REBOL scripts do not require any newlines to function properly. But aain, an index? into the sources would work. Brian; Always take my squawking for what it is, someone that thinks he knows but knows he doesn't, yet still wants to help. :) |
Sunanda 2-Apr-2008 [10075x2] | R2 can't do much with the call stack. R3 promises more, eg: http://www.rebol.net/r3blogs/0011.html |
and http://www.rebol.net/r3blogs/0075.html | |
Fork 2-Apr-2008 [10077x6] | Stack looks useful... though as I mention in my article I sort of feel that it's dangerous to do it that way, and am ok with narrower contracts |
Erm... I still can't quite figure out how to conveniently get my assert routine to access the system/script/header from the caller, without writing: | |
assert system/script/header 1 != 0 | |
I'd like some shorthand FOO so I don't have to type system/script/header each time, so I'd settle for: | |
assert FOO 1 != 0 | |
But if FOO is a function that lives in debug-functions.r then I'd need some parameter trick to access the calling context, the way bind uses a known-word for example. Is that the case? | |
BrianH 2-Apr-2008 [10083] | That won't work, even if you specify system/script/header at the call site, unless your assert statement is run during the execution of the script in question. Once a function is loaded, its source is gone - system/script/header refers to the currently running script. The only way to get your assert system working is with a preprocessor. |
Fork 2-Apr-2008 [10084] | Ah, well, I was thinking of doing that anyway. |
BrianH 2-Apr-2008 [10085x2] | REBOL doesn't have declarations - it has expressions that build functions and assign them to variables at runtime. |
You might consider extending prebol.r from the SDK - it has all of the preprocessing infrastructure built in. All you would have to do is add a #assert directive that would be replaced at preprocessing time with the info you want to log. | |
Fork 2-Apr-2008 [10087x2] | An option I considered was a refinement to assert, called /loc (for location) and let you pass in an identifying string for that assert. Then, a tool which goes through all the asserts in the code and if it doesn't have a location, add the refinement and a parameter based on a GUID. It will also make a database of file/lines for each location. Thereafter programmers can move them around without much trouble. |
Does R3 have guid! ?? | |
BrianH 2-Apr-2008 [10089x3] | You can make your own using binaries or strings, but nothing built in. |
Yet - user-defined datatypes aren't done yet. | |
In your case, filename, line and position on the line would probably be sufficient. | |
btiffin 2-Apr-2008 [10092x2] | Brian (fork); :) Check out rebol.org - pager.r for an attempt I made at keeping track of source line numbers. Again, some REBOL scripts are built without newlines. Best to keep index? values. imho. It's what I use for the word cross referencer I'm working on (forth style locate and tour) |
As far as I can figure, the only things in REBOL that cares doodle about newline is; the semi-colon comment, that newlines are retained in multi-line braced strings (and kinda in blocks) and a newline breaks a quoted string. | |
Fork 2-Apr-2008 [10094x2] | You can just call me Fork, that's fine, no offense taken. :) |
Seems to keep things clearer... and I can feel all hacker elite to be one of the few on here with a handle. :) | |
btiffin 2-Apr-2008 [10096] | Only add fork that time as this is a three-way Brian chat. :) |
RobertS 2-Apr-2008 [10097] | --[[ a Lua multi-line comment --]] but adding a hyphen as in ---[[ lets the commented block run and the --]] can remain in place as both bookends are now just -- single-line comments; really quite clever. Rebol could use ;{ and ;} where ;;{ opens up the 'commented' lines to run (not a block comment at that point) but leaves the 'markers' in place until debugging or profiling or unit test or whatever is completed; |
Henrik 3-Apr-2008 [10098x2] | dumb question: >> a: make object! [b: 'c] >> mold a == "make object! [^/ b: 'c^/]" ; c is lit >> mold/all a == "#[object! [^/ b: c^/]]" ; c is not lit I guess the question is why c is not lit for MOLD. It means that when you probe an object , words in an object appear lit, when they are really not. (Are they?) |
sorry, it should be "why is c lit for MOLD" | |
Anton 3-Apr-2008 [10100x4] | make evaluates the object spec block. Therefore, the lit-word is transformed into a word. |
mold/all, on the other hand, does not evaluate the object spec block. | |
compare probe load mold a probe load mold/all a | |
They both load the same. | |
Henrik 3-Apr-2008 [10104] | in your first reply, did you mean "mold evaluates the object spec block"? |
Anton 3-Apr-2008 [10105] | no, I definitely meant make. |
older newer | first last |