Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 20 2019 22:59
    @dockimbel banned @SmackMacDougal
  • Dec 03 2017 05:53
    @PeterWAWood banned @matrixbot
  • Sep 28 2016 12:19
    @PeterWAWood banned @TimeSeriesLord
  • Aug 13 2016 03:23
    @PeterWAWood banned @Vexercizer
Toomas Vooglaid
@toomasv
@BlairLW (Before @9214 gets to it, try to avoid the variable-word :smile: ) I'll try to cook an example.
BlairLW
@BlairLW
the word variable is "bad" in rebol?
Toomas Vooglaid
@toomasv
Strictly speaking, there are no variables in usual sense in Rebol/Red.
word: "I am not a variable!" 
view [t: field 150 button "Show" [t/text: word]]
Toomas Vooglaid
@toomasv
@BlairLW Example, why words are not like variables:
c1: object [a: 1] c2: object [a: 2] c3: object [a: 3]
set/only 'a reduce [in c1 'a in c2 'a in c3 'a]
a
;== [a a a]
reduce a
;== [1 2 3]
BlairLW
@BlairLW
@toomasv thanks. I discovered "form" problem solved :-)
Toomas Vooglaid
@toomasv
You are welcome! :smile:
Gabriele Santilli
@giesse

@NjinN async is tricky in REBOL 2. There's some info here https://codereview.stackexchange.com/questions/152718/minimal-async-web-server-in-rebol-2 but nobody has ever written good docs about it. If you can find it, Romano's atcp:// scheme may be the most complete and relatively user friendly implementation, otherwise my async:// scheme (linked from previous link) should work but you'll have to hunt around for examples on how to use it on the server side of things.

Generally speaking though, there are so many bugs and quirks in R2's async-modes that it's pretty hard to get a server to work reliably. You may want to use an existing solution like Uniserve or Cheyenne instead.

NjinN
@NjinN
@giesse Thanks a lot! I just want to write web page with Rebol in someway like PHP, it seems no server program support it. So I make a simple server program to implement that, there is no existing solution as i know.
Semseddin Moldibi
@endo64

@NjinN Also check https://www.cheyenne-server.org/ a web server written with Rebol and the author of Cheyenne is DocKimble, the author or Red as well.
It'a a full featured web server, natively support Rebol pages (RSP)

@ungaretti recently added a page about it on Helpin.red web site: http://helpin.red/AppendixII-WhilewewaitforfullCGI.html

NjinN
@NjinN
@endo64 Great, thanks
hiiamboris
@hiiamboris
I've come to seek your advice ☻ In case I don't see a polar bear in my kitchen...
Does it make sense to you that rotate of the Draw dialect currently rotates around 0.5x0.5 pivot? I think we should change it to 0.0x0.0 (see red/red#3504).
hiiamboris
@hiiamboris
Same question on scale
Toomas Vooglaid
@toomasv
@hiiamboris Seems correct:
im: draw 3x3 [box 0x0 2x2 pen red line 0x0 2x0 pen blue line 2x0 2x2 pen green line 2x2 0x2 pen yellow line 0x2 0x0]
view/tight  [box draw [scale 20 20 image im 0x0 2x2]]
image.png
Not only rotate and scale, but draw on first place :smile:
view/tight [box draw [scale 20 20 [
    box 0x0 2x2 pen red line 0x0 2x0 pen blue line 2x0 2x2 pen green line 2x2 0x2 pen yellow line 0x2 0x0
]]]
Toomas Vooglaid
@toomasv
image.png
hiiamboris
@hiiamboris
@toomasv It does not bother you that the scaling applies around the center of the top left pixel, not around the top left corner of that pixel?
Toomas Vooglaid
@toomasv
I mean, you are correct!
hiiamboris
@hiiamboris
Oh! Okay ☺
Toomas Vooglaid
@toomasv
From the other side, as a base of calculations, center-of-pixel seems ok. Think of e.g. line-caps and width:
view/tight [box draw [transform 0x0 90 20 20 50x10 [
    fill-pen orange box 0x0 2x2 
    pen red line-cap square line 0x0 2x0 
    pen blue line-cap round line 2x0 2x2 
    pen green line-cap flat line 2x2 0x2 
    pen yellow line-width .5 line 0x2 0x0
]]]
image.png
hiiamboris
@hiiamboris
I don't see how that would have affected line-caps and width... With upper left corner of the image as a pivot your command will be transform 0x0 90 20 20 40x0 instead. I think... Which is more intuitive, no? 2x2 * 20 = 40x40
You wouldn't have to manually add another 0.5x0.5 * 20x20 = 10x10
Toomas Vooglaid
@toomasv
That's true.
hiiamboris
@hiiamboris
What I really dislike about the coordinate system is that draw commands refer as 0x0 (line 0x0 ...) to the same pixel that you would later extract as image/(1x1). Simply. Annoying. ;) But I suspect this is not gonna change...
Toomas Vooglaid
@toomasv
Yeah, I have hit my head against this several times :dizzy_face:
nedzadarek
@nedzadarek

@hiiamboris I do not find this annoying.
draw/shape draws things in all direction (e.g. view [base draw [translate 100x100 line -2x0 -50x-55]]. It make sense that you start from 0x0 and move in any direction.
images and other series first index being 1 make sense too. I mean you want to a first element -> 1st.

ps. of course it is just my opinions. You can make (and I think you have already made) a contra-argument about 0-based indexing.

hiiamboris
@hiiamboris
Well I mean the amount of extra work required to properly subtract and add and otherwise take care of the indexes, and the effort it takes to keep in mind in what expression what origin you are using is annoying ☺
That and the fact that you'll have to tell everybody who uses draw that they have two different coordinate systems - one for indexes and one for commands...
I see even more complications though. When they make a pair! of float!s, there'll be a tough choice. Will we map all integer pairs to pixel centers, like 0x0 will be the same as 0.5x0.5? Or will we let the image lie mostly in the right lower quadrant and let it extend just half a pixel to all 3 other quadrants?
I think this one deserves a REP
nedzadarek
@nedzadarek
@hiiamboris excuse my ignorance, but what is the purpose of float-based pairs with the images/draw etc? You want to draw on exact pixel (using integers points): 42x42 not on not-precise point (using floats): 3.14x3.14.
hiiamboris
@hiiamboris
But I do want to draw on floats! I do want seamless animation, subpixel pen positioning, continuous scaling and on and on. Otherwise forget about vector graphics
Scaling is already alright though, as it's not dictated by a pair!
nedzadarek
@nedzadarek

@hiiamboris

But I do want to draw on floats!

but you only have integers

Otherwise forget about vector graphics

but isn't vector scaling/rotating indifferent? Using floats you may introduce some errors.

I'm still confused but I'm not good in the graphics.

hiiamboris
@hiiamboris
What's your point?
nedzadarek
@nedzadarek
My point is that you don't need float-pairs for such things.
hiiamboris
@hiiamboris
I do.
nedzadarek
@nedzadarek
If you think you need them then I bet you have valid reasons. It's just I don't see it. I won't talk about this more because I need to read some things on such topics.
hiiamboris
@hiiamboris
You ever used AutoCAD @nedzadarek ?
nedzadarek
@nedzadarek
@hiiamboris no
hiiamboris
@hiiamboris
I see...
BeardPower
@BeardPower
@hiiamboris Red does not support floating point pairs at the moment. Changing it could affect other parts. To make sure there are no issues with floating pairs, the team needs to discuss on that first.
hiiamboris
@hiiamboris
I understand. And will be happy to participate in the discussion ☻
BeardPower
@BeardPower
Having the origin points at the center of the pixel would be actually correct, as a pixel is dimensionless and it also is a question of sub-pixel rendering,
hiiamboris
@hiiamboris
Pixel is not dimensionless. Or I didn't get your point.
BeardPower
@BeardPower
A pixel is dimensionless because it's just a basic unit. That's why there is DPI, which is the actually defines the size of a pixel.
Having the origin point at the top left corner of a pixel and rotating it would not only result in a rotation but also in a translation.
Vladimir Vasilyev
@9214

My point is that you don't need float-pairs for such things.

In such case, can you draw an equilateral triangle using 3 line commands for me, @nedzadarek ?

hiiamboris
@hiiamboris
@BeardPower prove it.
BeardPower
@BeardPower
@nedzadarek You need floating point units because of the center of the pixels.