Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:34
    qtxie opened #5154
  • Jun 28 12:36
    hiiamboris commented #4988
  • Jun 28 07:52
    meijeru commented #5
  • Jun 28 07:50
    hiiamboris commented #123
  • Jun 28 07:50
    meijeru closed #123
  • Jun 28 07:50
    meijeru commented #123
  • Jun 28 07:45
    meijeru opened #123
  • Jun 27 10:28
    hiiamboris closed #5153
  • Jun 27 10:28
    hiiamboris labeled #5153
  • Jun 27 08:51
    qtxie labeled #5153
  • Jun 27 08:51

    qtxie on master

    FIX: issue #5153 ([Regression] … (compare)

  • Jun 27 08:51
    qtxie assigned #5153
  • Jun 26 12:57
    hiiamboris labeled #5153
  • Jun 26 12:56
    hiiamboris opened #5153
  • 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
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.
Gregg Irwin
@greggirwin
w-rule: [to end]
b-rule: [end: [to end]]
o-rule: object [end: [to end]]
oo-rule: object [a: object [end: [to end]]]
ooo-rule: object [a: object [b: object [end: [to end]]]]

count: 1'000'000
x: [loop count [[to end]]]
w: [loop count [w-rule]]
b: [loop count [b-rule/end]]
o: [loop count [o-rule/end]]
oo: [loop count [oo-rule/a/end]]
ooo: [loop count [ooo-rule/a/b/end]]

profile/show [x w b o oo ooo]
Time         | Time (Per)   | Memory      | Code
0:00:00.035  | 0:00:00.035  | 440         | x
0:00:00.042  | 0:00:00.042  | 284         | w
0:00:00.074  | 0:00:00.074  | 284         | o
0:00:00.084  | 0:00:00.084  | 284         | b
0:00:00.093  | 0:00:00.093  | 284         | oo
0:00:00.112  | 0:00:00.112  | 284         | ooo
Naturally parse needs to check for the new datatype as well, which adds to this. And this is just reading the value, not setting it. But if the user isn't paying the cost when the feature isn't used, this seems like a useful way to modularize rules. Of course, creating "modules" of common rules, assuming people use them, means many people are paying that price for common rules.
Oldes Huhuman
@Oldes
I don't say that paths have no cost.. just that using bind on a large block of rules is also not cheap.
Not mentioning that not every parse call must be in a tight loop.
Gregg Irwin
@greggirwin
Personally I think it's worth supporting.
GiuseppeChillemi
@GiuseppeChillemi
About opening a wish ticket: my feelings tells me that anything requested by me, because of my past exchanges with Doc and Vladimir, has an higher chance of being rejected. As I think this feature is very important, please someone else should take the task, so that another name appearing on the github ticket won't trigger automatic negative responses. Hovever, I will try to partecipate if I feel this won't damage the request too.
Gregg Irwin
@greggirwin
I don't think it's anything personal @GiuseppeChillemi, just that your wish tickets often push boundaries, where we tend to be quite conservative about what the core does versus what users do in their own code. This is perhaps the most difficult part of design: a lack of evidence and information. Putting things in the language is forever (nearly always), so if there isn't general consensus (given our small community), we play the waiting game.
GiuseppeChillemi
@GiuseppeChillemi
@greggirwin I don't think all of my ideas have been rejected because my exchanges with Doc and Vladimir: some were good, some were wrong, some were already possible without changing the language (I was inexperienced). But I feel this one is more important than the others, so if there is a chance my name could harm it being adopted, it's the time I should step back. I will write the next but not this one. ;)
theangryepicbanana
@ALANVF
is this official? looks cool af https://beta.red-lang.org/
gltewalt (The other Greg)
@gltewalt:matrix.org
[m]
Yes, just not quite ready yet
GiuseppeChillemi
@GiuseppeChillemi
I have added the path in parse request as comment to red/red#3528
Boleslav Březovský
@rebolek

I have some strange troubles with git, after doing git pull I get an error:

Your configuration specifies to merge with the ref 'refs/heads/master'
from the remote, but no such ref was fetched.

however, when I list remote branches, master is of course there. Anyone experienced same problem?

hiiamboris
@hiiamboris
Try comparing config to a fresh clone?
Boleslav Březovský
@rebolek
My repo says there is only one remote branch, IO and I'm not able to convince it that it's not true. I moved the repo elsewhere and made a new clone, I don't have time to argue with Git.
hiiamboris
@hiiamboris
likely some .git/config corruption.. for whatever reason
Greg T
@gltewalt
Did someone delete or rename a remote branch?
Boleslav Březovský
@rebolek
I don't think so, I had troubles with a master branch which obviously is still present.
Oldes Huhuman
@Oldes
Try main branch.. looks like Github is doing anti-slave movement.