Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 04 20:21
    greggirwin closed #29
  • Jan 04 20:17
    greggirwin closed #80
  • Nov 24 2018 00:23
    greggirwin opened #81
  • Sep 10 2018 06:43
    endo64 opened #80
  • Apr 17 2018 02:28
    dockimbel closed #77
  • Apr 16 2018 17:39
    Oldes reopened #77
  • Sep 25 2017 07:45
    Oldes closed #76
  • Sep 24 2017 14:29
    Oldes closed #77
  • Sep 23 2017 20:02
    Oldes edited #77
  • Sep 23 2017 19:14
    Oldes synchronize #77
  • Sep 23 2017 18:12
    Oldes synchronize #77
  • Sep 23 2017 18:08
    Oldes synchronize #77
  • Sep 22 2017 10:40
    Oldes synchronize #77
  • Sep 22 2017 10:35
    Oldes synchronize #77
  • Sep 21 2017 15:35
    Oldes synchronize #77
  • Sep 21 2017 15:31
    Oldes edited #77
  • Sep 21 2017 15:24
    Oldes synchronize #77
  • Sep 21 2017 13:04
    Oldes synchronize #77
  • Sep 21 2017 11:34
    Oldes synchronize #77
  • Sep 21 2017 11:06
    Oldes synchronize #77
Gregg Irwin
@greggirwin
There are a few others that can merge PRs for that repo, yes. We can open it up to more managers, but it hasn't been used much, so no discussion on that yet.
Maxim V
@maximvl
I'd love to continue putting code there but so far when I'm trying to make something I hit missing / undocumented things, there are about 5 Red programs I can't finish yet for different reasons :(
Gregg Irwin
@greggirwin
We're here to help. :^)
GiuseppeChillemi
@GiuseppeChillemi
@maximvl could you enumerate the "stoppers" ?
Maxim V
@maximvl
@GiuseppeChillemi main one being some unobvious crashes, like this one:
red/red#3080
and this: red/red#2614
I also faced some view bugs, they might be fixed on the new builds but I'd rather wait for a new stable release :)
it's more like the feeling that I can spend few days writing something which finally will be blocked by some bug =\
Nenad Rakocevic
@dockimbel
@maximvl Please advertise for your favorite tickets in red/bugs, as we are at a bugfixing stage before the new release.
Gregg Irwin
@greggirwin
@meijeru , https://github.com/greggirwin/red-code/blob/master/Showcase/tile-game.red doesn't work (hasn't for a while I'm guessing. Due to button size including OS metrics (e.g. you say 60x60 is what you want, but you get 62x62). Looks like I tinkered up https://gist.github.com/greggirwin/6d3c3adc9525cd759258f85be817dc45 some time ago in response. Would you review and decide what should be in the showcase repo?
Rudolf Meijer
@meijeru
I like your version (which does indeed work) for its generalization, which shows some nice properties of Red and VID in particular. So this one definitely has a place in the showcases. But a simplified (non-generalized) version which only updates the adjacency test to be metric-independent would also not be amiss, because it shows very well the compactness of Red and VID.
Gregg Irwin
@greggirwin
:+1: If you update yours, I'll look at adding mine.
Rudolf Meijer
@meijeru

I need to replace

unless find [0x60 60x0 0x-60 -60x0] face/offset - empty/offset [exit]

by

delta: absolute face/offset - empty/offset
        if delta/x + delta/y > 90 [exit]

that's all -- to remain as compact as possible.

You have access to red-code, and I don't do PRs, so please...
I checked that this works with the newest version.
Rudolf Meijer
@meijeru
I notice @rgchris is uploading some Rebol3 code. Would be nice to see how much work it needs in order to become Red (if that is his intention...)
Rudolf Meijer
@meijeru
On the other hand, this seems to be more in the world of Ren-C. Thus one can ask why the repository rgchris/Scripts is figuring in the Red progress site @fluxloop.
Rudolf Meijer
@meijeru
Sorry, that last addressee was @x8x rather!
Gregg Irwin
@greggirwin
@rgchris has ported some of his work to Red IIRC. We should certainly ask if he's OK with it, before diving in.
A lot of his stuff will take at least one core change. He uses use in a unique way to create contexts, which is very non-standard, and we don't have use in Red. It's inclusion is TBD.
Christopher Ross-Gill
@rgchris
@meijeru I'm tidying up my script library there. It was originally only Rebol 3 scripts (should work against the last published community build), but seemed the right place to put my Red and other scripts. I have been tempted to make hybridized scripts (the markup parser is probably the most ambitious), but I think that most would need a dedicated rewrite—especially (as is the case with AltJSON) if a goal is to work in compiled scripts.
Christopher Ross-Gill
@rgchris
I'd certainly have no problem if someone wanted to convert any of them—most all have the Apache license. It is my intention to convert them at some point (except where there's a good chance it'll overlap with built-in functionality or the standard library).
Rudolf Meijer
@meijeru
I have meanwhile looked a little at Ren-C and noticed that is drifting apart from Rebol/Red quite considerably. So a dedicated rewrite would indeed be necessary...
Christopher Ross-Gill
@rgchris
Yes—those scripts especially will need to be rewritten, but those targeting Rebol 3 Alpha (or indeed Rebol 2) should be a bit more trivial.
Rudolf Meijer
@meijeru
I am impressed by Toomas' thru op. It occurred to me that this can be used in the idiom foreach i 1 thru 15 [...] to emulate a for loop. And with an additional operator step which is make op! func [a b][extract a b] one can have foreach i 1 thru 15 step 2 [...]. This is of course not space- and time-efficient, but for rapid prototyping it could be enough. Because of issue #3344 one cannot use words instead of numbers, but that may come.
Boleslav Březovský
@rebolek
:+1:
Toomas Vooglaid
@toomasv
@meijeru Indeed! :+1:
Toomas Vooglaid
@toomasv
Something more convoluted:
step: make op! func [a [series!] b [integer!]][
    case [
        b = 0 [a] 
        b < 0 [reverse extract (last a) thru (first a) 0 - b] 
        'else [extract a b]
]]
>> foreach a 3 thru 10 step 2 [print a]
3
5
7
9
>> foreach a 3 thru 10 step -2 [print a]
4
6
8
10
>> foreach a 10 thru 3 step 2 [print a]
10
8
6
4
>> foreach a 10 thru 3 step -2 [print a]
9
7
5
3
Gregg Irwin
@greggirwin
I love these kinds of experiments. :^)
And thanks for weighing in @rgchris.
raster-bar
@raster-bar
Sorry if I missed something, but it looks like Red wiki is not a right place to discuss red/code repository, and there's no such place elsewere aside from this room, right?
raster-bar
@raster-bar
The reason I'm asking is that a wiki is a decent place for design docs
Gregg Irwin
@greggirwin
The wiki for each repo should have content related to that repo. Wikis are easy to change, so getting the content out there is the important step. After that, we can move it if a better place is decided on.
raster-bar
@raster-bar
I'm sorry I didn't realise it was used
Rudolf Meijer
@meijeru
I have published a function request-date which, when called, brings up a small month calendar with options to skip to next/previous month and next/previous year. Clicking a date yields the date! value as result. Call it with a date! argument to prefill a certain date, or with none to prefill it with today's date. The code is here
R cqls
@rcqls
@meijeru It looks great! Almost working on linux since I think it seems there is an issue with unview in red/gtk that I need to fix.
Toomas Vooglaid
@toomasv
@meijeru :+1:
Gregg Irwin
@greggirwin
Nice @meijeru! Note that if you select a day (e.g. 31st), then scroll the month to one that has less than that day number, it doesn't calculate correctly to keep the same day.
Rudolf Meijer
@meijeru
Astutely observed. I do -- naively -- date/month: date/month - 1, so you get from 31-Jul-2019 to 31-Jun-2019 which is corrected by Red to 1-Jul-2019automatically. The month scrolling should be more sophisticated.
But then again, what is "one month before 31st of July 2019"? How do you define that? And "one month before 31st of March 2019"? That could be 28th of February, but in 2020 it should be 29th of February. This becomes quite tricky.
So perhaps my naive approach is not too burdensome...
Gregg Irwin
@greggirwin
Here's an old bit of code:
set 'same-day-next-month func [date /local d] [
    d: date
    d/month: d/month + 1
    if d/day < date/day [d: d - d/day]
    d
]
And an old hack for finding the last day of the month (without using lists):
set 'last-day-of-month func [date /local d] [
    d: date
    d/day: 1
    d/month: d/month + 1
    d: d - 1
    d
]
Rudolf Meijer
@meijeru
Thanks for these hacks!
Gregg Irwin
@greggirwin
If there are less days in the target month, than the day currently selected, the least surprising thing seems to be to use the last day of the month. Without second-guessing things, or maintaining a flag during navigation, it does mean that you will change the day if you go 31-Mar to Feb, back to Mar. That's a problem.
Rudolf Meijer
@meijeru
I corrected the gist already and it works. t is true that this creates another problem as you mentioned. But at least the month is actually changed all the time.
Gregg Irwin
@greggirwin
:+1:
Rudolf Meijer
@meijeru
For the previous year, one gets "one year before 29-Feb-2020" as 1-Mar-2019 with my construction. This is probably correct, since people having a birthday of 29-Feb will celebrate it on 1-Mar in non-leap years... However, adjusting the /year component of 29-Feb-2020 gives a non-existing date. See the latest issue #3881 .
Toomas Vooglaid
@toomasv
@meijeru If you have time and interest may be you can compare with my date-picker
Rudolf Meijer
@meijeru
@toomasv You limit the years, and you avoid the above problem by losing focus on changing month or year. The use of range simplifies some formulations and makes for fewer LOCs (if you don't count the source of range, of course...).
Toomas Vooglaid
@toomasv

@meijeru Thanks!

You limit the years...

Years are limited in drop-down selection list, but any year can be entered in the box. No sense in providing list of all years for selection.

you avoid the above problem by losing focus ...

Yes, because that's the job of user to pick a date. But currently my picker doesn't actually return a date, only probes the picked value.

I agree about range usage.