AltME groups: search

well, I guess the obfuscation is fair enough since it's a user/password 
combination

Hi all. I've got an issue in REBOL2. I have a Win32 DLL (using library/load) 
that has an argument of char**. What does my make routine! need to 
look like to be able to handle this?

Okay, I'll give it a shot there, thanks.

Sorry, no there is not -- not online anyway.

You could download all the scripts and do a search locally with a 
few lines of REBOL code 
http://localhost/cgi-bin/download-librarian.r
(the scripts will all be in the /scripts/ folder)

Good news -- no absolutely positiioned DIVs, so it is a fairly fluid 
layout, will flow easily into most window size.


Bad news -- main frame of site is a table. Originally, it was nested 
DIVs but that caused some layout problems when displaying <pre> sections 
of code. Going to a table was a quick fix that has never been looked 
at again.

ok , I'll give it a try for fun...  :-)

sunanda, you might want to add an "extension" section to rebol.org 
where we may contribute C/C++ code to rebol.org... what do you think?


for tutorials and small projects it might be very usefull as a tool 
to help out other people into understanding how to use the extension 
API.

It's possible....But may take a while.

For now, you could publish extension code on REBOL.org as an article 
(or series of articles).

Guys, is there any strategy of how to distinguish R2 vs R3 script 
base? I know that there are header/library fields available, but 
apart from that, I expect almost zero compatibility between R2 and 
R3 script base, and users might be confused, why scripts don't work 
for them? Would R2 vs R3 script-base split be a good idea?

Something new in the Library....If you own scripts, you can add images 
to them to make it all a bit more graphic.

Only example to date here:
    http://www.rebol.org/view-script.r?script=ascii-chart.r

Notes about how to add images to yoour scripts here:
    http://www.rebol.org/boiler.r?display=script-images

Thanks to Maxim for the original change request.

rebol.org should have a new tag added:

 R3


since R3 just about every R3 scripts are incompatible with R2 it 
would be nice to have reference to what R3 scripts are available 
on rebol.org.


I ask this cause I want to upload an R3 BNF -> Parse grammer converter 
and I see no way to make it explicit in the gui that its an R3 script.

Anyone can add any tag to scripts....Click the [edit tags] link when 
logged on and looking at a script.
   http://www.rebol.org/boiler.r?display=st-edit-tags-help

ok, so my guess is to add r3 as a library *interface* supported tag 
in the left columns.

there is a tagged called r3-ready, but that doesn't rule out its 
a r3 only script.

so possibly the best would be to make it a standard like:

r3//only
r3//compatible
r3//incompatible

Is it not sufficient to set a minimum 'needs header?

Once we have a few with an R3 tag, it'll make sense to add R3 as 
a menu entry.

exactly... but just adding that button in the menu (even if there 
are only on or two script which are tagged atm) will help raise awareness 
about the need to tag stuff and to add new r3 content to rebol.org.


that's just my two cents... right now... rebol.org fives the impression 
it doesn't support r3 at all.  maybe a little post on rebol weekly 
to promote the use of r3 tags and a quiet request to carl to blog 
about it on the r3 blog, where MANY people go for r3 news.

But not in a way that looks weird when R2 and R3 roles are flipped.

It'd make some sense to add an [R2] tag to all existing scripts (we 
can do that automatically) and/or [R3//untested] tag.

But let's get some [R3] scripts first,  so we have  a_need_ to make 
the distinction.


A couple of my scripts should be tagged as [R3] -- I just never got 
a round tuit:
   http://www.rebol.org/art-display-article.r?article=j26z

maybe a simple part of header processing could be that when needs 
r3 is there... it is tagged as such automatically.

If you add a new script, yoy can add a (say)
  library: [r3: 'tested]
tag, and that will be picked up and used in the tag index.


The problem with updating the tags in the headers of existing scripts 
is that it is long-winded: you need to physically upload a new version.

Better just to retag via the [edit tags] link.

I am enhancing the rebol Haru PDF binding again , in the meantime 
I added support for getting position of current "text cursor" (which 
was the problem back then).. I needed it to detect when to go to 
new-page with pdf. Now I also added support for images (jpg and png). 
I am using Git so code is here: http://github.com/jankom/RebHaruPDF
.. it's still heavy in progress and there is a nicer OO interface 
than the one in sample_images.r (that is using the lowest level direct 
functions from binding because I am testing if it works at all with 
it)

Is there any way to produce a single animated  .gif file from ten 
frame files?   
This  script
http://www.rebol.org/view-script.r?script=animated-gif.r
runs animation in the gui. Can it be saved into a gif file?

Good...

frames must already be saved in GIF format (UnFREEz does no converting), 
and that they should be the same dimensions
If there  is a function in REBOL. It could be more convenient.

make-animated-gif:  func[images[block!] /size image-size [pair!] 
/delay [integer!] /loop]......................

How much bigger would it make REBOL?  If it's too large, a downloadable 
script would probably be better.

If it's that small, it should be possible to do a clean-room development.

It would be great for us to have a little "rent-a-reboler" site, 
at which anyone wanting REBOL features like this (or even scripts 
- any sort of development work), could post a job and developers 
could reply with bids.  That could give RT motivation to add features 
that only certain users are interested in initially, and I bet we'd 
see lots of features get added to REBOL3 as extensions.  I'd love 
to support REBOL by paying for little features that I need/want. 
 Animated GIFs are not a priority for me, but I can think of at least 
10 low level functions that I'd buy.

Make a list and let us know. And attach a number that we have a baseline 
to discuss about.

Pekr, I don't know, but maybe it's the wording? "Bounty" versus "rent-a-reboler". 
I haven't seen many examples of bounties that actually worked.

ok, i tried to take a bit different aproach. I thought, that I might 
support some efforts with 100 USD per month or two. I would choose, 
which project I would contribute to ... if there would be more such 
ppl, eventually willing to spend 50/month, our fellow rebol developers 
would not necessarily work for free. Even if it does not make one 
for a living, I think it might be at least nicely motivating ...

A bit OT here but: IMO what's required is a cooridnated approach 
for this. If everyone is doing a bit here and there, movement is 
to slow and spend efforts won't have the highst possible impact.

... conversely if the pieces are small enough, and can be done by 
one coder in a relatively short amount of time, many small pieces 
would get completed.  You know the saying, "pennies make dollars".

bounties have to be worth the time.  if I work  at X$ an hour and 
a bounty offers 1-2 hours worth of work for something that may take 
a day... its not worth it

Hooray, I finally found the Contribute A Script link !!

Just about everywhere; I found some faq or doc referring to the "control 
panel", which I couldn't locate. Eventually I realised that I needed 
to login as a library member, not just a regular member, so I created 
an account. Even after that it took a while :)

Anton reported that that algorithm the Script Library uses for suggesting 
script names when a name is mistyped was failing to produce some 
obvious matches.
Thanks Anton.
Algorithm tweaked.....Please suggest other improvements!

I'd suggest recognizing 3D as the beginning of a name could be an 
encoding error

Thanks for the comments, Graham.


3D....Possibly.....But there is one script whose name begins 3D (grandfathered 
in before we insisted names start witha letter), so it could be genuine.


Download....From the "sorry did you mean" page, you are one click 
away from the download link -- so would cluttering that page with 
extra links be that helpful to those who want to view a script.

True.....But the page you get to does have a "download script" link. 
 That is usable by REBOL.

Nice idea, Graham..... But the REBOL script might be a spider/inder 
like RIX; and so expects a HTML page.
We can't second guess cases like that.

But yeah, I think it should be a bit less work to change rebol.org's 
urls than improve rebol's path-thru.

yes you can ... because a spider will identify itself

No need for second guessing -- REBOL.org already has the "feed me 
a plain text" link -- use the Download script link for that.
That's simplicity......Isn't it!?

just a few characters difference

No, because you cause every single person who recieves a rebol org 
link extra work

A caveat for changing rebol.org's urls; there is a history of rebol.org's 
urls in mail postings etc. Changing them would invalidate those historical 
links (unless you also maintain support for those old links).

If it's a browser .. give them a browser approprate view

It is a tough problem...

Yes, a simple request, but a tough problem to get right in all practical 
cases.

Sunanda, how did you change the simetrics matching? (I noticed there 
were several algorithms in the simetrics.r file, so I suppose you 
 selected a better one.)

Thanks for retesting.

We use a couple of the algos, and then weight the results.


In addition, we do some other stuff -- like give additional weight 
if the first char matches; or if the lengths are similar.


And we gave some extra weight if the search string was fully contained 
within the script name (eg some bonus when matching "Apple.r" against 
"an-apple-script.r" (ignoring the .r of course).

What was missing was some extra weight if the script name was fully 
contained in the seach string (Money.r is fully wthin 3dmoney.r)....Adding 
that test raised its relevance.

Sometimes users ask for things that are not practical for other users, 
and thus us poor developers have to make choices that can leave some 
unhappy :)
Suppose I wanted this code to execute the first code block....

  do http://synapse-ehr.com/forums/showthread.php?120-RebGUI-table

....That's a reasonable request for me. But is it for all users, 
such as Rixbot?

Would a rebol function named "get-rebol.org-script" in your user.r 
(or built-in to rebol) help alleviate the problem at all?

It would just convert a "view-script.r" link into a "download-a-script.r" 
link, so that users take, for example, the money.r link and type 
this into their console:


 do get-rebol.org-script http://www.rebol.org/view-script.r?script=money.r

Simpler for _you_ if we change the source; but perhaps not simpler 
for _others_ who expect it as it is.

Another even easier solution (easier for me, anyway:)


....In theory, REBOL does hunt through verbiage looking for "REBOL 
[" and starts executing from there.


So If the R2/R3 interpretor also de-escaped strings like < then 
the view-script would be executable.
Why not curecode/RAMBO that as a request!?

My 2 cents:  I like the way the links work now, but I also echoed 
Graham's request when I initially started using rebol.org.  Is it 
possible to hide a copy of the actual (downloadable script) code, 
at the top of the web page, so that it's executable by REBOL, but 
not visible by those using a browser?

Nice idea. But there is no foolproof way that does not leave someone 
with a screenreader seeing (or not seeing) double.

Also, may mess things up for (the few I hope) people with early CSS 
implementations in their browsers.


I'm still looking for an argument to convince me that one URL should 
serve two separate resources depending on user-agent sniffing.

I am downloading http://www.rebol.org/download-a-script.r?script-name=test-framework.r

Okay, I get a script library header inserted, which uses CR LF to 
terminate lines.

But at the very end, there's a trailing single LF.

Ah, and there's a single leading LF as well, right before the script 
library-inserted header.

We've had all sorts of fun trying to get the line endings to work 
for everyone.


There's a magic, undocumented URL parameter you can add to the URL 
that might make a difference on your platform.

It is MODE=????


I'll just cut'n'paste the comment from the download-a-script source... 
it may help explain it:

;; mode=windows -- the default. Makes LF or CR into CRLF
;; mode=binary  -- sends file as binary
;; mode=carl    -- saved and reloads file first as Carl thought
;;                 this would fix the problem
;; mode=text    -- the old default. Works in most cases. Just
;;                 prints the file (so sends whatever line
;;                 terminations work on the platform the library
;;                 is running on.

But somewhere on the way something inserts a single LF as the very 
first and very last character.

Wait, I'll upload a hexdump of what actually goes over the wire.

That is most certainly a bug.

Certainly a bug .... and a bit of a mystery. not obvious where they 
come from (not yet, anyway)
The dev server does it right, live does it wrong.

And the download-script script generates the output by using PRINT. 
Which leads to a terminating LF on Linux and a CRLF on Windows.

Switch the output generation to use PRIN instead (and add a `prin 
crlf` at the start/end if you really want the extra whitespace), 
and it should be fine.

Possible.....But if you add &mode=binary, then do not do a PRINT.
We do this instead
   set-modes system/ports/output [binary: true]
    insert system/ports/output script-source
And that also looks wrong on live.

Most likely you have a PRINT before and after that.

We have a print for the HTTP headers, prior to chaning modes....that 
may be part of the problem.

Yeah, the HTTP header print sounds like a very plausible source.

If you do a PRINT instead of the PRIN in this case, that will lead 
to exactly the extraneous LF we are seeing.

If you have a shell on the live server, `head script.r | hd` will 
give you a hexdump of the start of a stored script.

Thanks for the advice and debugging.
I'll look at it more seriously tomorrow.

Meanwhile, does this experimental option make it bettter or worse:

    http://www.rebol.org/download-a-script.r?script-name=base-convert.r&mode=andreas

Thanks Oldes, Peter and Petr for the Rebbies nomination. If I win, 
I will of course use my year to work with children and animals for 
world peace. However, it would be better to honour someone who has 
been more active in 2010; my REBOL work has been a bit sparse this 
year. So good luck to all the nominees!


Anyway, enough of self-promotion. Oldes nomination citation notes 
that he does not like the look of REBOL.org. That's a widely shared 
sentiment, and I have much sympathy for the view.


However, REBOL.org is to some extent skinnable – look here, if you 
are logged on, for user-contributed alternative CSS schemes:
    http://www.rebol.org/css-available.r


The current look'n'feel came about by a competition for a better 
look (won by Roland Hadinger) a few years ago. And it is MUCH better 
than what we had before!


If anyone wants to craft an alternative look'n'feel, please feel 
free.


Of course, just changing the CSS is not everything: contents of menus, 
access paths, etc may need tweaking to work well with a new look. 
I am happy to play along with any suggestions that may help anyone 
who is devising a site make-over.

In 3 out of 4 of those cases you gave, they couldn't be finished 
because of security issues that could not be fixed in R2. R3 has 
made a lot of headway towards fixing those security issues, mostly 
because we kept them in mind when we made the incompatible changes 
(not everything was incompatible). As more participants use REBOL 
more, the limitations of it will be resolved. That is how the R2 
backports started, for instance.

but at least I can point out that's a shame to waste those things 
that made rebol a different thing ...

BrianH ok I know R3 was made to make the world a better place blah 
blah etc... AMen,  but thing is since t least those past 5 years 
not a world on the futur possible for those technologies and now 
it's even worst you are all tuned with the same borring song "If 
you are not happy do it yourself yoh!!!"

it's gone at a point that french community some month ago was represented 
by me, didec, maxim, steeve and Dockimble  and Greg that's all

Shadwolf: <fine 1024 script burried one on top of another :) nice 
!!!>

They are all tagged in various ways to help catalog and find relevant 
scripts, eg:
   http://www.rebol.org/st-topic-details.r?tag=type//game

The tagging could do with an overhaui, so if you want to contribute 
to the quality of the Library without contributing scripts, then 
being a retagger is one way to achieve that.

I improve some more the rendering now the file gnome-keyboard-dev.svg 
is fully and perfectly rendererd. I put a red pen-fill color for 
identify all primitives that needs fill:url related gradient

and I'm close to have found a solution to one of my problems regarding 
to the transformation matrix

Features still on the work table are:
- SVG Transformation translation (mostly matrix)
- SVG Gradient translation (linear partern radiant)

- SVG drawing primitives (some drawing primitives are not supported 
actually ) 

- SVG Animation translation (don't know if this is a usefull and 
suitable fonctionnality tellme what do you think about it)

FYI: 

Ed Pegg writes "I did a survey of all available vector-based drawing 
programs, in anticipation of SVG in the 

next Firefox. I found 29 different vector drawing programs. Of these, 
14 were free or open source. More than I 
expected. Did I miss any good ones?"
 

http://developers.slashdot.org/article.pl?sid=05/08/02/0117224&from=rss

personnaly I'm working with InkScape a very good SVG software...

transform problem are on their way to be solve gradient too by cyphre 
and  Carl those  two things are the most blockant problems until 
they are not completly solved we can't expect to have a full working 
SVG rendering engine  -> most of SVG  imagines use transform effects 
and gradients this means    that if we want to get a pretty good 
and reliable SVG engine we have to fixe those two issue. SVR rendering 
engine is a good and hudge test upon AGG integration to REBOL/View 
and it allows us to embetter it !!! 


Once we get a fully working engine with basic human understandable 
algorithm i will start the  optimisation process using  parse (but 
to be franck i don't  know how parse will react in front svg row 
data or how will be the time to dev this parse based SVG engine ... 
 in all cases I think the actual engine have teached me a lot arrounf 
the SVG to AGG adaptation process so i hope the translation to parse 
and parse/rules will not be too hard and too long)

well last thing i can say is that SVG rendering  engine is very high 
on my task  list ( task number one) i worked on the adding of some 
other new drawing primitive  (image rect, circles). I will continue 
to  work on the close support of all SVG datas that can have a meaning 
in AGG context. SVG rendering engine is  a   2   weeks of work only!!! 
... until i fall on the gradient and transforms problems so this 
ensure us advancing on this project will be very fast once we solve 
bugs in REBOL/View related to AGG (wich is in progress actually)

In the futur i hope we will use a lot svg in dynamic  drawing composition.

for me to be honnest the advantages of  using SVG instead of images 
 are a lot this is a quick list of my thoughts on what can be done 
with  SVG format.
 - easier embeding of graphical content
- resizing auto ith not grphics quality loss
- cheap but sharp skining 

 - graphical content of an  User  Interface  very low because rebol 
 is pretty able to  work with compression of text content ( compress/decompress)

A little sample to enlight this  compressed SVG file with blender 
logo ->  less than 500 octets (any size can be applyed with no graphic 
loss (aliasing, color loose, blur, pixelisation etc..) )  a fixed 
jped for same content will use  around  50ko. This means less datas 
in memory to as graphic pixel tables are very heavy in VM memory

- Dynamic graphical content. some thing like text scrolling or efffect 
like Flash ones but with  a  reduction of  1000  of the data and 
memory use SVG use a labeling system for  each graphical content 
that compose the image we can provided a tiny system to handle easy 
animation and show/hide of graphical content using raw rebol commands 
-> this will make pretty easier the realisation of dynamic animations 
in rebol ViD content and  as any REBOL/View face is DRaw/AGG capable 
the effects that we can create isn the futur with this idea will 
have no limits  -> this means too to have a pretty fast and ell designed 
SVG engine (that's my actual path on research)

One other big advantage is that there is a lot of high-quality SVG 
in the public domain, and it's growing fast.

shadwolf, a good example to use with your svg renderer is the word 
map with political borders (public domain license) http://www.mappinghacks.com/maps/world_borders.svgz

surfing around on internet i found another common application for 
SVG -> graphs representation. The idea is inspired by  a ruby project 
http://www.germane-software.com/software/SVG/SVG::Graph/#N10034. 
To do this in rebol we need teh ability to save data in an image 
PNG. The way we can use a thing like this could be to use a simple 
rebol draw based dialect to write  the graphs if we are in REBOL/view 
application the  graph is isealy shown if we need to show the  graph 
in webrowser we can have  2  external sources SVG  and PNG.  For 
importing graphs from another application the SVG is the best way. 
 So our REBOL::SVG::GRAPH would be able to import graphi content 
from a SVG file, output SVG and PNG files, render graphs to REBOL/view 
draw pane, propose a simple way to implement graphs  using a rebol 
dialect.

hum new rebol/view have save/png hability woooooooooooopy so there 
is nothing that prevent us to make a  graph /AGG/SVG/PNG  dialect 
 ^^

on a project like an svg graph system save.png take really all it's 
sens imagine a way to make easyly graphs with your rebol GCI to display 
graph stats in your web pages for example

as svg or as png in a simple and easy way

you have that in php and in ruby or php for example why not rebol 
starting from the point that rebol dialectal ability is incredible 
it's a pitty to not take advantage of it  and show ppl hat rebol 
can apport on this particular application and this gives a good way 
to compare rebol to the other scripting language

would following news help us to get AGG - SVG compatible gradients? 
It regards AGG 2.4, new branch of AGG, and I am sure we will get 
it ported to REBOL too ...


New utility class template is added, gradient_lut. It allows you 
to easily create a color LUT for gradients from a set of color stops 
as they are defined in SVG, section Gradients and Patterns.

okay  thank you for the  link  in my  idea  my  SVG/REBOL graph render 
should be easy to  use and render basical graphs  using  a psecial 
graph dialect  but  ofcourse it  will be enhanced afterward...