Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

probe/dump-binary survey

 [1/14] from: greggirwin:mindspring at: 2-May-2004 11:23


Jaime et al JV> Greg, I think your suggestion that probe should produce output JV> similar to dump-bin by default is great. I hope Carl goes for it. For those who don't know, I posted this idea on an AltME world for comment. For those who want to express an opinion on the matter, there are two scripts below; one for Core, and one for View. All they will send to me is your answer -- how strongly you agree that PROBE should produce output like dump-bin, given a binary! value. I'll collect the results and pass them on to RT. Thanks! -- Gregg ; Core Version address: head reverse [moc--gnirpsdnim--niwriggerg] reply: func [data] [ print "^/Sending response..." send address rejoin [data] print "^/Thanks!" ] reply ask { Enter YES or NO (case insensitive) if you feel strongly one way or the other, or a value between 0 and 1 to indicate agreement (0 = no, 1 = yes, ..5 = don't care). Should PROBE produce output like Jaime's DUMP-BIN function? } ; View Version address: head reverse [moc--gnirpsdnim--niwriggerg] reply: func [data /local wnd] [ h/text: "Sending response..." show h send address rejoin [data] h/text: "Thanks!" show h ] view layout [ h: h3 as-is {Should PROBE produce output like Jaime's DUMP-BIN function?} text as-is {(Select an answer or set the slider value and click Send)} across text "NO!" [reply 'no] tab text "don't care" [reply .5] tab text "YES!" [reply 'yes] return answer: slider 210x16 return across button "Send" [reply answer/data] ;button "Quit" [quit] ]

 [2/14] from: antonr:lexicon at: 3-May-2004 4:45


Please consider that molded code should be able to be loaded back by rebol. So I say no. I have no real objection to including dump-bin named as is though. Anton.

 [3/14] from: rotenca:telvia:it at: 2-May-2004 23:50


Hi,
> Please consider that molded code should be able to be > loaded back by rebol. So I say no.
I agree. Could be an help service. --- Ciao Romano

 [4/14] from: greggirwin:mindspring at: 2-May-2004 18:13


Hi Anton, AR> Please consider that molded code should be able to be AR> loaded back by rebol. So I say no. AR> I have no real objection to including dump-bin named as is AR> though. Are you saying that because that's how PROBE currently works (i.e. the molded result is exactly what is displayed)? We wouldn't be affecting molded code in general, only what PROBE prints out. The value given to PROBE would be returned just as it is today. It's important to think of all these things though, so thanks very much for commenting! -- Gregg

 [5/14] from: moliad:aei:ca at: 3-May-2004 4:38


nope, no go... just like probe on an object! does not do a dump-obj. especially since we often insert a probe within a line to get status at that moment, like just before an assignment... dump-bin would break that behaviour. dump-obj as a function is cool though, so it should be included :-) -MAx

 [6/14] from: moliad:aei:ca at: 3-May-2004 4:47


> Are you saying that because that's how PROBE currently works > (i.e. the molded result is exactly what is displayed)? We wouldn't > be affecting molded code in general, only what PROBE prints out. The > value given to PROBE would be returned just as it is today.
that would make probe a little obsure ... probe is meant to show what the code is ... internally. If you want to make a datatype based format print or probe, then user should just implement this: dprobe: func [data][ switch/defsault type?/word [ object! [dump-obj data data] binary! [dump-binary data data] ;--- add you favorite datatypes here--- :-) ][ probe data data ] ] its so easy to do that there is no point in obfuscating probe IMHO... -MAx

 [7/14] from: greggirwin:mindspring at: 3-May-2004 3:54


Hi Max, MOA> especially since we often insert a probe within a line to get MOA> status at that moment, like just before an assignment... dump-bin MOA> would break that behaviour. It shouldn't, unless I'm missing something. What it displays and what it returns are two different things. MOA> that would make probe a little obsure ... probe is meant to show MOA> what the code is ... internally. This is interesting. I've always thought of PROBE as "show me the value" where the inlining aspect was the big benefit, but that it didn't add as much as it could for certain types of values (e.g. binary! and bitset!). That is, I thought in terms of "show me the value in a way that is most informative to me." A molded object spec is just that, as are many values they way they are returned. A date! displayed as fields/values for each possible refinement would be more verbose and less useful than a plain molded date. MOA> If you want to make a datatype based format print or probe, then MOA> user should just implement this: MOA> dprobe: func [data][... I would probably call that one DUMP. :) Having a single wrapper for all datatypes would be a good thing in any case, and I think we also need to have a way to see the values as PROBE returns them today (inlining it can be a big benefit after all). What about a refinement on PROBE that makes it produce DUMPed output? -- Gregg

 [8/14] from: andreas:bolka:gmx at: 3-May-2004 16:36


Monday, May 3, 2004, 11:54:45 AM, Gregg wrote:
> This is interesting. I've always thought of PROBE as "show me the > value" where the inlining aspect was the big benefit, but that it > didn't add as much as it could for certain types of values (e.g. > binary! and bitset!).
that's interesting indeed ;) different mindsets :) i'd strongly urge for 'probe to be not modified for exactly the same reasons anton, romano and maxim have expressed before. i see probe as a way to inspect data and be able to immediately use the probe's output (e.g. feed the probe'd data back into a REBOL console).
> What about a refinement on PROBE that makes it produce DUMPed > output?
no problem with that ;) however i don't how the refinement would produce a benefit compared to adding just another function (named dump, for example :) -- Best regards, Andreas

 [9/14] from: antonr:lexicon at: 4-May-2004 0:46


Gregg, I'd like probe to remain the simple function that it is. Something beautiful about it. (I think, because there is nowhere for bugs to hide in there..:) Anton.

 [10/14] from: antonr:lexicon at: 4-May-2004 0:44


I was thinking the dump-bin output could be made loadable again, therefore achieving orthogonality: what can be molded can also be loaded. The output could be changed like so: dump-bin to-binary "abc" make binary! #{6162 63} ; 0000: abc dump-bin to-binary "all the king's horses and all the king's men" make binary! rejoin [ #{616c 6c20 7468 6520 6b69 6e67 2773 2068} ; 0000: all.the.king.s.h #{6f72 7365 7320 616e 6420 616c 6c20 7468} ; 0001: orses.and.all.th #{6520 6b69 6e67 2773 206d 656e} ; 0002: e.king.s.men ] Maybe some other tricks to get more syntax out of it, and get the line numbers back to the left... Anton.

 [11/14] from: greggirwin:mindspring at: 3-May-2004 15:23


Hi Anton, Andreas, et al AR> I'd like probe to remain the simple function AR> that it is. Something beautiful about it. I agree that simple is beautiful; if we can simplify all the code that uses this functionality, even at the expense of a little added complexity inside, that's a gain IMO. Of course, it's all a balancing act to find out what we think will be best. So, here's PROBE today: probe: func [ {Prints a molded, unevaluated value and returns the same value.} value ][ print mold :value :value ] And here's what it might look like with a /dump refinement: probe: func [ {Prints a molded, unevaluated value and returns the same value.} value /dump "Display data in non-molded format" /local fn ][ either not dump [print mold :value][ fn: switch/default type?/word :value [ object! [ either attempt ['face = value/type] [:dump-face] [:dump-obj] ] binary! [:dump-bin] ;function! [:dump-func] ;bitset! [:dump-bitset] ][:probe] ] fn :value :value ] The complexity jump is quite large. :( Any other candidate host functions that map to this functionality? GI> What about a refinement on PROBE that makes it produce DUMPed GI> output? AB> no problem with that ;) however i don't how the refinement would AB> produce a benefit compared to adding just another function (named AB> dump, for example :) Ahhh, this is a really good question, which came up during the development of the ROUND function for View 1.3. Should it be separate functions for each type of rounding, or a single function with refinements? In the end, we went with the latter because the function itself gives you context. * If you type HELP ROUND, you instantly see all the options in one place * It's a way to group things * It means less to learn because once they find PROBE they've already found DUMP * You don't have to add extra docs in each one saying how they differ, you just doc the refinement that tells how it changes the behavior. I'm not trying to defend the idea here, just rambling. It's not always appropriate, and it can be misused of course, but I think there's a lot of leverage to be applied with refinements. They do make it much more important that you choose your words well and wisely though. -- Gregg

 [12/14] from: nitsch-lists::netcologne::de at: 4-May-2004 4:48


On Montag, 3. Mai 2004 23:23, Gregg Irwin wrote:
> Hi Anton, Andreas, et al > > Any other candidate host functions that map to this functionality? > > GI> What about a refinement on PROBE that makes it produce DUMPed > GI> output? >
probe/dump - longer to type. when i debug i want it short. even shorter than probe. ?? most of the time. How about a name similar to that? but 'dump would work.
> * It means less to learn because once they find PROBE they've > already found DUMP >
how about: help probe ->> Prints a molded, unevaluated value and returns the same value. similar: ? ?? dump Also !>>help dump Found these words: dump-face function! Print face info for entire pane. (for debugging) dump-obj function! Returns a block of information about an object. dump-pane function! Print face info for entire pane. (for debugging) there is a convention to call such functions dump-*. that the integrator is called 'dump makes sense.
> * You don't have to add extra docs in each one saying how they > differ, you just doc the refinement that tells how it changes > the behavior. >
that can be done with a naming-convention too. because "help round-" would do a "wildcard-search". In case of 'round i prefer refinements. In case of 'dump i would prefer lots of dump-* and dump with a switch. because then its most easy to add new dumpers. We could even have some support to add new dumpers on the fly, like add-dump ['my-type = val/type][dump-my-type] Now instead of "send" i could not resist to press "hack", and here is: ;the code dumpers: copy[] add-dump: func[guard dump-how][ insert dumpers reduce[guard dump-how] ] dump: func[val][ bind dumpers 'val foreach[guard dump-how] dumpers [ if attempt guard [attempt dump-how break] ] :val ] add-dump [true][probe val] ;demo, dumping an object smart ctx: context[type: 'my-type id: 1 lots-of-data: [1 2 3]] dump 1 dump ctx add-dump ['my-type = val/type][ print ["my-type" val/id "has" length? val/lots-of-data "elements"] ] dump 1 dump ctx ;demo-output ;first unsmart 1 make object! [ type: 'my-type id: 1 lots-of-data: [1 2 3] ] ;now smarter 1 my-type 1 has 3 elements
> -- Gregg
-Volker

 [13/14] from: andreas:bolka:gmx at: 4-May-2004 15:31


Tuesday, May 4, 2004, 4:48:10 AM, Volker wrote:
> Now instead of "send" i could not resist to press "hack", and here > is:
thanks for sharing! i found it exciting that this piece of code uses loads of typical REBOL idioms - i.e. it can be considered a piece of REBOL wizardry :)
> ;the code > dumpers: copy[]
<<quoted lines omitted: 29>>
> 1 > my-type 1 has 3 elements
-- Best regards, Andreas

 [14/14] from: maximo:meteorstudios at: 4-May-2004 11:59


> how about: > help probe ->> > "Prints a molded, unevaluated value and returns the same > value. similar: ? ?? > dump"
YESS A "RELATED:" or "SEE ALSO:" WOULD BE SOOOOO USEFULL IN ALL RT Function defs. AND A CLASSIFICATION ID TOO ... like in the ref-words doc where there the words are split up/sorted in different related domains. then you could do help/topic series and get a list of 30 words, all related to series...
> there is a convention to call such functions dump-*. that the > integrator is > called 'dump makes sense.
yess!!! my opinion too.
> > * You don't have to add extra docs in each one saying how they > > differ, you just doc the refinement that tells how it changes
<<quoted lines omitted: 3>>
> round-" would do > a "wildcard-search". In case of 'round i prefer refinements.
because all the different operations are related... me too
> Now instead of "send" i could not resist to press "hack", and here is: > > ;the code
[...] cool stuff :-) -MAx

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted