Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 24 03:47

    qtxie on IO

    FIX: more error handling when c… (compare)

  • Jun 22 08:45

    qtxie on IO

    FIX: remove some debugging logs. (compare)

  • Jun 20 20:03
    dockimbel closed #4314
  • Jun 20 20:03
    dockimbel labeled #4314
  • Jun 20 20:03
    dockimbel labeled #4314
  • Jun 20 20:03
    dockimbel labeled #4314
  • Jun 20 20:03
    dockimbel commented #4314
  • Jun 20 20:02
    dockimbel commented #4314
  • Jun 19 16:16
    hiiamboris commented #4528
  • Jun 19 16:15
    hiiamboris unlabeled #4528
  • Jun 19 12:10
    hiiamboris commented #5137
  • Jun 19 12:07
    hiiamboris commented #5137
  • Jun 18 17:06
    greggirwin commented #4662
  • Jun 17 16:15
    hiiamboris commented #5151
  • Jun 17 03:26

    qtxie on IO

    FIX: use b-allocator to copy bi… (compare)

  • Jun 16 18:26
    greggirwin commented #2838
  • Jun 16 02:23

    qtxie on master

    FIX: para breaks `toggle` align… (compare)

  • Jun 16 02:23
    qtxie closed #5152
  • Jun 15 21:56
    hiiamboris commented #5152
  • Jun 15 21:29
    ALANVF opened #5152
hiiamboris
@hiiamboris
@greggirwin if `"..."` is so utterly bad for you, let's consider just an empty issue # "...", because #` is completely ugly and using only opening quote makes no sense to me, if it's quotes they should be on both ends. # "..." is somewhat similar to char syntax though. But then any other symbol allowed in issues will be better than backquote. ## #! #$ #% #= #| #/ #\ #. #~
hiiamboris
@hiiamboris
I would still prefer them backticks on both ends. Simplest syntax and readable unless your font is not monospace and you're not using syntax highlights.
hiiamboris
@hiiamboris
(editor) (gittard) (GUI console) this is how it looks for me without any steps done on my end (and I would highlight backticks and all operators)
hiiamboris
@hiiamboris

A poll from Nenad ☻

Which way to you guys use try most of the time?

  1. To silence errors, as in if error? try [...] [..after-error recovery..]
  2. To catch errors and process them later, as in set/any 'err try [...] (... later err is processed...)
  3. I never used try

Please post your answers into thread if possible. Thanks.

18 replies
Oldes Huhuman
@Oldes
@hiiamboris may I ask what we should expect as a result of this poll? And why Nenad is not asking here himself anymore?
Gregg Irwin
@greggirwin

The new try/keep feature is there now, for including stack traces, but we don't know if it should be the default.

Being on Gitter can take a lot of time and pull focus. When there's a Nenad sighting, people tend to swarm. I'm sure he'll reappear here at some point.

gltewalt (The other Greg)
@gltewalt:matrix.org
[m]
Instead of try / catch, how about... what amounts to enums... custom types that only accept a few things - either succeeds or the error message comes directly from the type
Gregg Irwin
@greggirwin
Do you mean like specific exception values, as in Java?
Note that in Red try/catch isn't a thing. We have throw/catch which is not specifically error related, but is about general non-local flow control.
gltewalt (The other Greg)
@gltewalt:matrix.org
[m]
See the chit chat room
Yes, but when I think of try, catch is always trying to sneak into to the party
Into
Gregg Irwin
@greggirwin
Ah, category types as in Haskell, got it.
Gregg Irwin
@greggirwin
For those more versed in Java and Haskell, the two approaches are very similar, aren't they? You have to declare all the specific exception/error types that can occur, and then you need to specifically handle each one of them.
gltewalt (The other Greg)
@gltewalt:matrix.org
[m]
I dont know much about Java. I could never bring myself to use it.
gltewalt (The other Greg)
@gltewalt:matrix.org
[m]
You handle each one in a custom type that ideally models your application - for error messages, There's a separate type for recovery.
Gregg Irwin
@greggirwin
It's an age-old question, without a single answer that is right for every situation. Treating errors symbolically moves toward general symbolic computing, which Red is well suited for.
karthik
@kskarthik:poddery.com
[m]
Does red standard lib has http server ? That would be useful
Boleslav Březovský
@rebolek
@kskarthik:poddery.com that certainly would be :-) Current Red’s IO is pretty limited, you can do requests and not serve anything, however, there’s IO branch with the new IO which can do both and you can write a HTTP server with it. I am working on one and I believe there will be some simpler variant in the standard library (basic HTTP/1.0 server can be done in few lines).
Boleslav Březovský
@rebolek
Here’s the server in action
it’s not much, I know :-)
karthik
@kskarthik:poddery.com
[m]
@rebolek: nice!!
Boleslav Březovský
@rebolek
@kskarthik:poddery.com Thanks! My current focus is not content, but strong server security by default where it does not stand very bad
hiiamboris
@hiiamboris
Looks like we've got trojans uploaded to our wiki. I reverted it and reported it using GH form, for now.
karthik
@kskarthik:poddery.com
[m]
@hiiamboris: github wiki's are editable by anyone. Better to move wiki to version control
hiiamboris
@hiiamboris
If that repeats we should consider it. OTOH, being editable is convenient for us all.
Gregg Irwin
@greggirwin
Thanks for taking care of that @hiiamboris.
GiuseppeChillemi
@GiuseppeChillemi

Do we have a function that creates a contex and binds the following code to context it running?

I want to create a with function:

with [a: 33 c: 33] [...code...]

Which is equivalent to:

do bind [...code...] make object! [a: 33 c: 33]

But I would like to know if it already exists.

Feedback is welcome, as there are many variants out there and it's likely something we will make standard.
GiuseppeChillemi
@GiuseppeChillemi
This would make elements setting in objects really fluent.
Oh my God, I have deleted everything instead of editing it! :-(
GiuseppeChillemi
@GiuseppeChillemi

Here I am again:

Why not allowing path in parse SET? It would make setting values in context very easy: (Please pardon me the wrong usage of IFbut I have still not studied it)

valid?: func [data test-name] [
   result: switch test-name [
           size [either data ... [true] [false]]
           position [either data ... [true] [false]]
   ]
]

options: [size 00x200 position above]
ctx: make object! [
   size: none
   position: none
]
parse options [
    set ctx/size 'size pair! (if not valid? ctx/size 'size] [fail!]
    set ctx/position 'position word! (if not valid? ctx/position 'position] [fail!]
]
Note: options: [size 300x200 position above]
But Gitter removes the number 3 for no reason!
Gregg Irwin
@greggirwin
@dockimbel noted red/red#3528 that path's higher overhead is a primary reason they aren't supported. However, if you don't use paths and aren't penalized, I don't see why those who want to use them shouldn't be allowed to. As long as they don't complain about performance. If there's no wish ticket for that, feel free to open one.
Toomas Vooglaid
@toomasv
@GiuseppeChillemi You can bind the rule to ctx. E.g. working example:
between?: func [data min-test max-test][
    all [min-test <= data max-test >= data]
]
valid?: func [data test-name] [
    switch test-name [
        size [all [between? data/x 250 500 between? data/y 200 400]] 
        position [find [above below left right] data]
    ]
]
ctx: make object! [size: none position: none]
options: [size 300x200 position above]
parse options bind [
    'size set size pair! if (valid? size 'size) 
    'position set position word! if (valid? position 'position)
] ctx
== true

ctx
== make object! [
    size: 300x200
    position: 'above
]
GiuseppeChillemi
@GiuseppeChillemi
@toomasv thanks, I know this tecnique but it has 2 drawbacks: you can't use it on blocks; the more the size of the context words, the more the probability it uses words between parens (in case of longer and parse rules and code in parens).
*in case of longer parse rules and code in parens
Toomas Vooglaid
@toomasv
@GiuseppeChillemi What do you mean in (1)? Do you mean subrules as named blocks? For (2) you can use @hiiamboris' bind-only to pin-point binded words; or even bind same word to different contexts in different parts of the rule.
hiiamboris
@hiiamboris
Don't forget you can write parse options [set ctx/size ..] as parse options reshape [set !(in ctx 'size) ..]. See reshape
You get precisely bound words this way.
You pay a little cost of preparing your rule block, but you don't pay extra during parsing.
GiuseppeChillemi
@GiuseppeChillemi
@toomasv I simply mean:
struct: [size "aaa" position "bbb" color [background none text none]] 
options: [size 300x200 position above background red]
parse options [
    'size set struct/size pair! if (valid? struct/size 'size) 
    'position set struct/position word! if (valid? struct/position 'position)
    'backgound-color set blk/color/background word! if (valid? blk/color/backgropund 'colors)
]
GiuseppeChillemi
@GiuseppeChillemi
@toomasv @hiiamboris Bind-only and Reshape are nice functions but the former does not use path notation; the latter uses it but statically, at rules block binding.
I prefer having the path notation
1) to keep the flexibility this gives to me when set word is expressed as setrule: [set word]
2) to avoid loosing myself when mentally transforming complex Parse rules !!! (Like multiple stacked compose). I am human and I have my limits.
hiiamboris
@hiiamboris
Why stack compose?
hiiamboris
@hiiamboris
Anyway, paths are cleaner but are not gonna be there anytime soon (unless you PR it and defend ;)
GiuseppeChillemi
@GiuseppeChillemi

@hiiamboris

Anyway, paths are cleaner but are not gonna be there anytime soon (unless you PR it and defend ;)

The ultimate defense is simplicity. As "stacking compose" I mean the code practice where you nest multiple compose calls, which can be generalized as "the code practice where you have to transform the block of code multiple times under compose/reshape like functions". This forces you to keep in mind the reshaping/transformation mechanisms of the functions you are using for this purpose; multiple meta states of the code block; the relevant elements; the final version of the code and where it will interact. Paths are simple, visible, straightforward with no layer of complications: what you see is what you manage.
The second side defense is @greggirwin one: if you have heavy overhead only when using them, well it's your choice as no one will have penalties for these features.

GiuseppeChillemi
@GiuseppeChillemi

I have looked at red/red#3528: Doc refers to tight loops overhead in a scenario of parse reducing word to their content for RULES, like

>> rules: [end: [to end]]
== [end: [to end]]
>> parse "foo" [rules/end]
== true

Which usually happens far more frequently than set ctx/key in my usage scenario. But even as rule word reduction, you should not have any overhead in standard usage if you put the check for path after parse check for word as once a "word" is found, the extra check for "path" is not performed. In any scenario, you have overhead only if you use paths, it's your choice!

Oldes Huhuman
@Oldes
Paths should be supported imho. I believe that using bind as a workaround is much heavier solution than processing paths.