Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 02 17:18
    greggirwin commented #200
  • Nov 02 15:09
    qtxie commented #200
  • Nov 02 14:26
    hiiamboris edited #200
  • Nov 02 14:21
    hiiamboris edited #200
  • Nov 02 14:17
    hiiamboris opened #200
  • Nov 01 22:28
    greggirwin commented #199
  • Nov 01 22:28

    greggirwin on master

    docs-cs: Repairs and missing tr… docs-cs: filio Merge pull request #199 from To… (compare)

  • Nov 01 22:28
    greggirwin closed #199
  • Nov 01 19:56
    Tovim opened #199
  • Oct 04 18:23
    greggirwin opened #198
  • Sep 17 22:14
    greggirwin commented #192
  • Sep 17 22:14

    greggirwin on master

    docs-cs: recent changes (image.… Merge branch 'master' of https:… docs-cs: cs\datatypes\map.adoc… and 1 more (compare)

  • Sep 17 22:14
    greggirwin closed #192
  • Sep 16 07:43
    qtxie transferred #197
  • Sep 16 07:39
    meijeru opened #197
  • Sep 15 18:30
    Tovim reopened #192
  • Sep 15 18:30
    Tovim closed #192
  • Sep 15 18:29
    Tovim reopened #192
  • Sep 15 18:28
    Tovim closed #192
  • Sep 15 18:19
    Tovim synchronize #192
Greg T
@gltewalt
Here a little tutorial on Blogger code highlighting, but an extension would have to be made for Red. Looks like they use Regex via JavaScript
Oldes Huhuman
@Oldes

How do you colorize RED code for HTML publishing ? (Blogspot, wikis...)

I would recommend using this: http://rebol.desajn.net/highlight/demo/

I don't remember why it is not in official version.
Oldes Huhuman
@Oldes
Ah... here it is... highlightjs/highlight.js#988 If someone wants to volunteer to move it far, I would be more than happy as I don't have much time for it.
Or you can just use my version as the problems were mostly related to language autodetection.
Rudolf Meijer
@meijeru
For information: I consider the hex-bigint branch sufficiently evolved to start tracking it in the specs document. Perhaps some comments will emerge. Where I have to second-guess the design I will hopefully get some answers.
Boleslav Březovský
@rebolek
:+1:
Gregg Irwin
@greggirwin
That's fine, but know that it's an early work in progress, so may see changes.
Rudolf Meijer
@meijeru
I did the bare minimum, and in reading the code I see many gaps, so I keep this as the skeleton for later additions.
Gregg Irwin
@greggirwin
:+1:
BeardPower
@BeardPower
@meijeru Is the available EBNF spec of Red/System up to date?
Rudolf Meijer
@meijeru
@BeardPower Short answer: no. Longer answer: I am working (on and off) on the update; about 90% finished. Hope to finish before end of year.
BeardPower
@BeardPower
@meijeru :+1:
amreus
@amreus
Why does Github wiki search return non-existing and duplicate pages? Bit annoying. Not sure what can be done since it's a Github problem. Example search which returns 9 results where only 2 or 3 are correct: walkthrough
amreus
@amreus
@ne1uno Thanks. Your link gives better results. Wish I didn't need to remember a work-around.
ne1uno
@ne1uno
I think anyone who can edit the front page could add a search box. there is the github advanced search too
Greg T
@gltewalt

If you’re in the Wiki, you can search under Pages. No duplicates.

https://imgur.com/a/Snof1th

Vladimir Vasilyev
@9214
@meijeru any idea what that is?
>> type? point!
== datatype!
Rudolf Meijer
@meijeru
It is a future datatype for three-dimensional coordinates, whose name has already been defined, but that is all, no implementation yet. In the specs document, it figures as TBD.
Phryxe
@Phryxe
Red/System Implementation Todo-list on Documentation page links to start page of the Wiki. I don't see the todo-list there ...
Semseddin Moldibi
@endo64
Todo list removed (archived may be) from the wiki. We need to update the R/S docs.
Team notified to update the web site, thanks for pointing that out.
Nenad Rakocevic
@dockimbel
@9214 point! is a datatype introduced to expose specific info (a slot with 32-bit integers) from Parse's internal stack in Parse event functions. It's a WIP, and meant primarily in its future final form for 3D representation (and eventually coordinates if a suitable literal format is found).
Vladimir Vasilyev
@9214
@dockimbel cheers Doc.
Vladimir Vasilyev
@9214
@meijeru cannot find this in your conversion matrix:
>> to integer! #abcd
== 43981
Hex-like issues can also be converted to binary!
>> to binary! #abcd
== #{ABCD}
Rudolf Meijer
@meijeru
to integer! <issue> is described in the specs section 5.4.5; to binary! <issue> is indeed missing -- thx for pointing that out, I will add it
Rudolf Meijer
@meijeru
BTW in the specs document there is no conversion matrix as such -- if you really referred to one, I suppose you mean the one in red/docs/conversion-matrix.xlsx made by dockimbel; that is not maintained by me, so if you want that kept up-to-date you should make an issue in the red/docs repository
Vladimir Vasilyev
@9214
@meijeru thanks, I should've checked your spec more closely; now I also see that binary! conversion is covered in 5.4.10.
Rudolf Meijer
@meijeru
I am reviewing the argument-types for all built-in functions. I will report here about findings. The first finding is the following -- not a new issue, but something to be observed: argument types for routines are severely restricted, namely they may only be the single word any-type! or else a single type name that is eitherinteger! float! or logic!, or one that has a Red/System struct! alias defined that describes a value slot of that type. I had already raised issue #2642 in this connection, but now I have seen a new consequence: a routine that works for both word! and lit-word! arguments, must have any-type! for its argument, and do the type check in R/S in the body; thus the routine spec block has less documentation effect, if you see what I mean.
Second finding: the argument type for the source function is any-word! and any-path but in the body of source the argument is supplied to get/any which only allows word! and path. Thus source can restrict its argument also to these two types. Is this worth an issue?
Rudolf Meijer
@meijeru
Third finding: absolute is defined on char! values -- this makes no sense. Note that sign?, positive? and negative? are NOT defined on char! values. Again, worth an issue?
Rudolf Meijer
@meijeru
Fourth finding: reduce accepts any-type! i.e. including unset! and compose accepts only default! i.e. without unset!.
Greg T
@gltewalt
If you can do arithmetic in char!, they should all be defined
Rudolf Meijer
@meijeru
So according to you, either all of absolute, positive, negative and sign, or none of them?
Greg T
@gltewalt
Yes, or none of them
Rudolf Meijer
@meijeru
Will you make the issue?
Greg T
@gltewalt
I can, yes
Boleslav Březovský
@rebolek
char! was always (silently) considered (unsigned) integer!.
Rudolf Meijer
@meijeru
Fifth finding: to-pair with a single percent value is accepted, but with a block of two values they may not be percent. Is this inconsistency disturbing anyone?
Greg T
@gltewalt
Get "Math or number overflow" with char! arithmetic, when going negative, so your first suggestion would be the correct one - remove absolute
Greg T
@gltewalt
@meijeru I think you got char! added to absolute #2700
Single percent value seems to always give 0x0
Rudolf Meijer
@meijeru
I did not remember. @dockimbel added absolute to char! in order to avoid a problem with mod(ulo). That single percents always give 0x0 comes from truncation, of course. Try to pair! 100% it will give 1x1.
Semseddin Moldibi
@endo64
This room is for docs repo hence # 2700 goes to issue 2700 on docs repo which is not exists. red/red#2700 is the correct link.
and, or, xor also works with char!
Rudolf Meijer
@meijeru
All operations on integers that have not got to do with sign are OK.
For char! I mean
Gregg Irwin
@greggirwin
On routines, thanks @meijeru. @gltewalt would you start a page for routine! values, or a wiki page where we can note things that are outside the scope of the spec doc?