AltME groups: search

hehe... I've been trying things for 15 minutes and just as I write 
this... I finally get it... hehehe   'END.

Can you give us examples of these words, you want to get recognized 
by parse? Then it may be easier to give opinions.

You should examine the "Idioms" section to get the idea.

[set var end] sets the var to none; [copy var end] sets to none in 
R2, the empty string/block in R3; [thru end] doesn't match, so it 
should just get a warning in case the rules were written to expect 
that; [opt end] is definitely legit; perhaps [any end] and [some 
end] should get warnings for R2, but keep in mind that rules like 
[any [end]] and [some [end]] are much more common, have the same 
effect, and are more difficult to detect; [into end] properly trigers 
an error in R2 and R3 because the end is not in a block, while [into 
[end]] is legit and safe.

(mm, not sure why the copy/past was messed up. i hope you get the 
idea anyway.)

Here's the R2 version of TO-CSV and TO-ISO-DATE (Excel compatible):

to-iso-date: funct/with [
	"Convert a date to ISO format (Excel-compatible subset)"
	date [date!] /utc "Convert zoned time to UTC time"
] [

 if utc [date: date + date/zone date/zone: none] ; Excel doesn't support 
 the Z suffix
	either date/time [ajoin [

  p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2 " "  ; or T

  p0 date/hour 2 ":" p0 date/minute 2 ":" p0 date/second 2  ; or offsets
	]] [ajoin [
		p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2
	]]
] [
	p0: func [what len] [ ; Function to left-pad a value with 0
		head insert/dup what: form :what "0" len - length? what
	]
]

to-csv: funct/with [
	"Convert a block of values to a CSV-formatted line in a string."
	[catch]
	data [block!] "Block of values"
] [
	output: make block! 2 * length? data
	unless empty? data [append output format-field first+ data]

 foreach x data [append append output "," format-field get/any 'x]
	to-string output
] [
	format-field: func [x [any-type!]] [case [
		none? get/any 'x [""]

  any-string? get/any 'x [ajoin [{"} replace/all copy x {"} {""} {"}]]
		get/any 'x = #"^"" [{""""}]
		char? get/any 'x [ajoin [{"} x {"}]]
		scalar? get/any 'x [form x]
		date? get/any 'x [to-iso-date x]

  any [any-word? get/any 'x any-path? get/any 'x binary? get/any 'x] 
  [
			ajoin [{"} replace/all to-string :x {"} {""} {"}]
		]
		'else [throw-error 'script 'invalid-arg get/any 'x]
	]]
]


There is likely a faster way to do these. I have R3 variants of these 
too.

Here's a version that works in R3, tested against your example code:
>> a: deline read clipboard://
== {a,      b ,"c","d1
d2",a ""quote"",",",}

>> use [x] [collect [parse/all a [some [[{"} copy x [to {"} any [{""} 
to {"}]] {"} (keep replace/all x {""} {"}) | copy x [to "," | to 
end] (keep x)] ["," | end]]]]]
== ["a" "      b " "c" "d1^/d2" {a ""quote""} "," ""]


But it didn't work in R2, leading to an endless loop. So here's the 
version refactored for R2 that also works in R3

>> use [value x] [collect [value: [{"} copy x [to {"} any [{""} to 
{"}]] {"} (keep replace/all any [x ""] {""} {"}) | copy x [to "," 
| to end] (keep any [x ""])] parse/all a [value any ["," value]]]]
== ["a" "      b " "c" "d1^/d2" {a ""quote""} "," ""]


Note that if you get the b like "b" then it isn't CSV compatible, 
nor is it if you escape the {""} in values that aren't themselves 
escaped by quotes. However, you aren't supposed to allow newlines 
in values that aren't surrounded by quotes, so you can't do READ/lines 
and parse line by line, you have to parse the whole file.

CSV is not supposed to be forgiving of spaces around commas. Even 
the "" escaping to get a " character in the middle of a " surrounded 
value is supposed to be turned off when the comma, beginning of line, 
or end of line have spaces next to them.

Funny, for my purposes it has to get over 100000 lines before it 
starts to be large :)

The app I'm building now requires RebGUI and so I get to know it 
a little bit.

As for the installer, I'm waiting for Carl to come out of his cave 
and submit his installer mezzanine fixes from 2.7.7 so we can get 
started on fixing it.

And please get rid of the auto-public-directory-creation.

>> secure b
** Script Error: Invalid argument: b
** Near: secure b
b was treated as a word like 'allow   'ask ,
so use :b instead, to get its value

If anybody can get Carl to contact me... maybe we can figure out 
what's happening. I don't seem to be able to reproduce this outside 
of that so far.

Has anyone used Edgar Tolentino's Imagemagick helper under 2.7.7? 
In WinXP I get REBOL saying:

---------------------------
REBOL/View: rebol.exe - Unable To Locate Component
---------------------------

This application has failed to start because X11.dll was not found. 
Re-installing the application may fix this problem. 
---------------------------
OK   
---------------------------

trying to get the newest windows version now

The problem with ImageMagick was that the API was a moving target. 

So the script I submitted worked only for that specific version of 
ImageMagick.

Since Qtask is not currently using ImageMagick now, I don't know 
when I can get back to work on it again.

I suggest to do what Gregg is suggesting at this time.

Carl, how possible is it to get UNBIND ported to R2 as a native for 
2.7.8? It's the only thing missing from R2/Forward so far.

(BTW, I get to say this because the first 64 CPU OS architecture 
I helped design was in 1981 at HP.)

Yay, do I get a t-shirt? :) Or at least a button "ask me about Haiku 
R3".

so to get a greater than we have to do

>> 10x0 = max 10x0 11x0
== false

Still really off-topic for this group. We're trying to keep this 
group on-topic for the discussion of R2 releases, so valuable information 
doesn't get buried in the torrent.

? 
max 10 9  = 10
max 11 12 = 12

you get the area which encloses both

using MIN on offsets and MAX on size you get the enclosing box


when you use MAX on offsets and MIN on size you get the intersection 
of both boxes

no there are a lot of mezzanines in dev chat ready for the 2.7.8. 
  AFAIK, Carl either works on R3 or R2. not both... right now, he 
is working on R3 so until we get another big release (the one with 
extracted view) I would't bet on a 2.7.8.


though I have been using a few of the functions with dev chat which 
Brian coded for R2/forward.

its also possible that with the AGG fixes done or pending, we might 
get a 2.7.8 beta which has current mezz code and the bigger native 
changes pushed to a 2.7.9 release... but I'm just throwing a guess 
in the air.

I've never previously experienced a problem when waking my Mac.


I only encounter the problem with the test library I have written 
in Free Pascal, I couldn't reproduce it with a C library with the 
same functionality.


It could be the Pascal written library, I'll do some tests on Windows 
(not VM) and Liunx when I get a little more time.


I'm a little suspicious of View 2.7.7 because when I tried Jaime 
Vargas's Callback test it crashed with a bus error.

I just wish there where a version without sandbox.  its VERY annoying 
to install, on vista it took me a full evening to get it to work 
using -qs properties.

Anton: regarding the DRAW fonts on Linux. The font redering is supported 
(at least it worked on all distros I had to use in recent 3 years 
or so). The essential problem is how to automatically get the paths 
to your Linux truetype fonts so you don't need to specify the font/name 
with absolute path as it is now....

If anyone knows about any efficient method how we could get path 
to the font files on Linux so it works on all distros let me know. 
Solving this issue would definitely improve the DRAW font usage a 
lot.

its hard when the damn paths are so obscure that you need to call 
the OS using libs to get the paths confidently.
its hard when those paths change all the time.
its hard where there are more than one path per application.


its just really complex when the darn paths could be simple... even 
on linux, they keep changing the paths almost every release on some 
distros.. it gets ridiculous.

The only weirdness in Vista/7 comes from the need to support roaming 
profiles. Windows is built around multi-user, multi-computer use 
over a whole enterprise. It took them a while, but they are finally 
starting to get it right in Vista/7. The only sucky things come from 
having to run apps that don't play by the 10+-year-old rules. So, 
would you prefer that those workarounds be gone and not be able to 
run AltME on Vista/7?

when you do a dirlist in rebol, you get the english name (like "users" 
instead of "utilisateurs")

that's the point of having a full VM installed in the transition 
period.  yess it takes disk space, but at least you only keep the 
legacy things within the legacy environment.  they could have gone 
100% 64bit for example and not have to support 32 bit modes within 
the 64 bit and also distribute a 32 and 64 bit version, things like 
that where there are already many *current* apps which fail in one 
or the other.  my friend can't get her camera to work on windows 
7 cause its only compiled as a 32 bit app (drivers and all).  but 
she was forced to use a 64 bit win7 because of support issues.

What was always missing in R2 was the ability for a programmer to 
get system information in easy to use way.

user-name (actuall real login of running task)
user home and related dirs

things like that which should be in the next release, especially 
if you are going to rummage through all of this.


I used routines to get to some of this, but I think it would be nice 
if this was built-in.

What was always missing in R2 was the ability for a programmer to 
get system information in easy to use way....I used routines to get 
to some of this, but I think it would be nice if this was built-in.


So every one of these concepts needs a runtime setting that tells 
user scripts where stuff goes.

Agree++

The runtime is /View doing something other than installing itself. 
And it needs settings, cross-platform settings that are made available 
inside /View without any script needing to check the registry of 
call GET-ENV, for scripts to know where to put or look for the stuff 
they need to run.

The dehex in that process is the one that we need to get rid of.

brian .. I agree.. the hexing should stay in the url datatype until 
the actual network scheme requires to handle it.  % characters are 
valid url so they should not get "fixed"

This is one reason why I wrote a rest protocol.  The http protocol 
seems designed to get content the same way a browser would.  But 
as more services use http more completely, things like automatic 
redirects and thrown errors for 4xx/5xx status codes are not helpful 
(and good luck getting headers and content then).

R2 is currently in maintenance mode, with an emphasis on backwards 
compatibility. Sometimes we get new backported features from R3, 
but for the most part it is only bug fixes. The main project is R3 
now.

Windows Phone 7 won't get a REBOL version without a ground-up rewrite, 
as the platform doesn't allow native code. Older Windows Mobile releases 
never were supported, though R3's host kit could in theory support 
them.

Some of what is coming in 2.7.8:

- Bug fixes and enhancements to improve Cheyenne, and other apps 
that have to do similar stuff.

- Some native fixes for non-Windows platforms, particularly Linux.

- Environment variable stuff: GET-ENV expansion on Windows, SET-ENV, 
LIST-ENV

- Function fixes: RUN enabled, LIST-REG/values, possibly TO-LOCAL-FILE

- R2/Forward: FUNCT/extern, LAST?, COLLECT-WORDS, EXTRACT fixes, 
ASCII? fixes, LATIN1? fixes, INVALID-UTF?, CD, LS, MORE, PWD, RM

- (Still pending) Natives: ASSERT, APPLY, RESOLVE, FOREACH set-word 
support

And from View in Sept 26

and ...


keys: list-reg/HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts"
    probe keys


    keys: get-reg/HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" 
    "URW Palladio L Italic (TrueType)"
    probe keys


    keys: exists-reg?/HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts\URW 
    Palladio L Italic (TrueType)" 
    probe keys

produces this

[]
URWPA32_0.TTF
false

Those are not keys, those are values. LIST-REG/values will get those.

What we got in 2.7.8, that I know of:

- Bug fixes and enhancements to improve Cheyenne, and other apps 
that have to do similar stuff.

- Some native fixes for non-Windows platforms, particularly Linux. 
See ACCESS-OS.

- Environment variable stuff: GET-ENV expansion on Windows, SET-ENV, 
LIST-ENV

- Function fixes: SELECT object!, FIND object!, RUN enabled, LIST-REG/values

- R2/Forward: FUNCT/extern, LAST?, COLLECT-WORDS, RESOLVE, APPLY 
fixes, EXTRACT fixes, ASCII? fixes, LATIN1? fixes, INVALID-UTF?, 
CD, LS, MORE, PWD, RM

Yes, yes  ..  so to try to get to the bottom of this - what shoud 
the true byte count of that VIEW exe be, please ?  thanks

Does 2.7.8 support get-words with paths? eg :obj/get-my-data

I think Peter might be asking about this sort of usage case:
     o: context [test: 3]
     a: 'o
     b: 'test

    o/:b   ;; this works
    == 3 
    :a/:b  ;; this fails
    ** Script Error: Cannot use path on word! value
    ** Near: :a/:b

    get in get a b   ;; this works, but it is hardly elegant
    == 3

I thought :a/b is a get-path! as a whole?

Here's my issue though I'm still running 2.7.5

>> f: func[][1]                
 
>> o: make object! [my-func: :f
]
>> b: reduce ['my-func :f]     
 
== [my-func func [][1]]

>> :o/my-func
== 1

>> :b/my-func
== 1


As you can see the value is being evaluated when using a "get-path!". 
Rebol3 simply presented the unevaluated value which is what I had 
expected.

(no get-word in the value)

No I didn't so let me rephrase my question. Is the  get-path! type 
supported in 2.7.8?

Btw, I'm currently connecting from the train on the road back to 
Paris at 200km/h using the train's wireless network! (I guess it's 
using a satellite connection, because latency is high and upload 
speed very very low). Nice technological achievement anyway...if 
only the train could get to destination without being, on average 
20mn late, that would be even greater! ;-)

Cheyenne presentation slides are available here: http://cheyenne-server.org/blog.rsp?view=25

There aren't much slides because the focus was on the coding demo.


Demo files won't be added until I get home, no way to maintain a 
SFTP connection long enough from here to upload them to Cheyenne 
site.

Doc, could you add the pdf ? I can't get the presentation.

someone should get the info to Carl, maybe he will stop breeding 
chicken and start coding R3 again :-) (just a joke - I have nothing 
about breeding animals :-)

Then something is wrong with the basic setup. When starting boron-gl 
alone, you should get a normal Boron console where you can try some 
functions

By the way, it looks like we'll be able to get a video stream up 
next time

it's like

a: []
a: [1 2 3]


how come? that after no insert at all I get three elements in an 
(originally empty block? ;-)

I came across the issue as I was trying to run REBOL/Services under 
Cheyenne in GCI mode. I have found that 0x0D bytes get changed to 
0x0A, it doesn't matter what they are preceded or followed by.

I also found that 0x0D0D gets converted to a single 0x0A.

That must have changed in later version. I tested such things deeply 
1-2 years ago and wrote a document, that I sent to Carl. Back then 
I noticed:

>> 2.2#
** Syntax error: Invalid "integer" -- "2.2#"


, and I suggested, it should be an invalid decimal, not invalid integer. 
Today I get:

>> 2.2#
== #.2#

There are many such situations.

trying to get info on a file via ftp using to long version of teh 
port spec as my user name is an email address:

fport: [
    scheme: 'FTP
    host: "ftp.example.com"
    target: %/file.txt
    user: "bill@ example.com"
    pass: "vbs"
]

I can read it with "read fport"

but I can not get other info from it like:

print modified? fport

Whats the method here?

Again, this might be a Graham question: I'm still working with that 
video encoder which uses http to communicate. They have a .cgi script 
which downloads the recorded video file from the internal SD card 
to the requester. My problem is the content I receive is somehow 
different than the files which I can download via a browser and of 
course will not play. I still using your http-tools to GET/POST. 
My initial thought was that  data returned is somehow being translated. 
Any thoughts?

I am making a simple (I hope) worfkflow prototype and want to use 
REBOL objects which I can SAVE and LOAD.  A workflow object!  to 
have a node-map collection in it of simple nodes of the workflow 
graph.   Source ->A -> B -> SINK where the workflow knows about the 
next node and status. Externally there is UI to support the work 
part ... which is URL data on a given node.   Looks like it fits 
into Cheyenne RSP well - maybe zmq when I get a bit further along. 
  Save a flow in process as a .txt file using SAVE/ALL filename.txt 
work-flow-instance.   But no success with work-flow-instance: LOAD 
filename.txt        Do I have to BIND on LOAD to re-instantiate the 
object?

What do you get when you do a load?

I get the same results on Windows. When I assign a block with the 
same contents to a directly, it all works. It looks like LIST-ENV 
is building a bad block.

Hm, maybe what I call integer refinements shouldn't be allowed at 
all, as I see no point in them. I can't get the desired path using 
integer refinements as in:

>> to-path [blk /2]
== blk//2

The correct way is:

>> to-path [blk 2]
== blk/2

So if integer refinements are useless, what's the point?

No kidden, people get confused:

>> f: func [/2] [if 2 [print "It's 2!"]]
>> f
It's 2!
>> f/2
It's 2!

I can even write

>> f/3
It's 2!

In R3, at least we get:

>> f: func [/2] [if 2 [print "It's 2!"]]
>> f
It's 2!
>> f/2
** Script error: incompatible refinement: 2

But the refinement is still valid.

rename capabilities in file handling do not normally allow paths 
to be used (in the OS itself).  otherwise these are a called 'move 
file operations. 


e.g. if you try using paths with rename in the DOS shell, you get 
errors.

Sorry, the actual decision was in a different ticket, but the discussion 
was in #743. Sometimes it can be a problem to make multiple tickets 
for the same problem, as opposed to different parts of the same problem; 
it can get a little confusing. Stuff like this is why we rearrange 
tickets more now.

The original design of REBOL has many many great ideas. It's just 
the implementation, that isn't good enough in many cases. With these 
new explanations, the whole thing just get more complex, which isn't 
good. My view is, that it's better to stick with a simple design 
and work on getting that implemented.

It used to be generated, but Carl says it's faster. I don't doubt 
him, because I've used dozens of parser generators before and that 
always seems to be the case. Sometimes you can get faster generated 
parsers, but generated lexers are usually slower because they're 
table-driven rather than code-driven. The advantage to generated 
lexers is that they are easier to write for complex lexical rules; 
for simple lexical rules, it is usually worth hand-coding.

If I in a function have a local variable, v, but I want the value 
of a variable v in the context outside the function, I can write:

get bind 'v bound? 'f


, where f is the name of the function. Is that the way to do it, 
or is there a better way? Full example:

>> v: 1
== 1
>> f: func [/local v] [v: 2 get bind 'v bound? 'f]      
>> f
== 1

It's for the parse function, I'm working on, and I want to be sure, 
I don't get a local var, if vars are used in the parse rules.

Tonight's Moment of REBOL Zen:

Literal and Get Arguments in R2

see: http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.2

These functions use Literal Arguments:


 ++ -- ? ?? cd default deflag-face first+ flag-face flag-face? for 
 forall foreach forskip help l ls map-each remove-each repeat secure 
 set-font set-para source

This function uses Get Argument:

	quote

It could be questioned, why functions like

	get set unset in catch throw checksum


, which all have arguments named WORD, don't use Literal Arguments?

Lit-word arguments are for functions that treat words as keywords 
or part of the syntax, or for interactive command line functions 
that are supposed to act like shell funcs. If you use lit-word arguments, 
you can't easily generate the value passed using an expression, especially 
in R2 - in R3, those expressions can be put in parens, as is emulated 
in the R2 mezzanine backports of R3 functions that take lit-word 
arguments. For instance, if you made GET take a lit-word argument, 
GET IN wouldn't work.

The date! type is a datetime type with an optional time portion. 
We can get rid of the time portion already. What do you want that 
we don't have already?

For me the issue is that when dealing with dates, I want to get only 
the date, but it it's a date with no time portion, then date/date 
gives you an error.

Given that R3 might get some restrictions, maybe having the /utc 
option like NOW would be better. Like this:

to-datetime: func ["Converts to date! value." value /utc "Universal 
time (no zone)"][

    value: to date! :value unless value/time [value/time: 0:00 value/zone: 
    either utc [0:00] [now/zone]] value
]

But that is starting to get more confusing, since /utc would only 
affect date values without times specified, not convert ones with 
times specified. It might be better to just say that it adds 0:00+0:00 
if not otherwise specified, since that is how dates are defined for 
date arithmetic compatibility between dates with times specified 
and those without.

Given that R3 might get some restrictions
 on the use of /local (there was a blog about it).

There are many competing and conflicting standards for how to format 
dates - REBOL just picked one of the international standards that 
looks more human-readable than most. You can get at the component 
parts if you want to format them differently.

True, we just get unintelligble scientific notation

Geomol, in R2 when you pass a word to a get-word parameter, the value 
assigned to that word is passed instead. There may have been a good 
reason for this initially, but in the long run it turned out to be 
a bad design choice, and was fixed in R3. It has nothing to do with 
the any-function! types.

There is a similar special case for when you pass a get-word value 
to a lit-word parameter, bot in R2 and R3. R2's APPLY function has 
code to undo these special cases, and R3's APPLY doesn't do the special 
evaluation; APPLY is used to break the evaluation rules, often for 
safety.

Tonight's Moment of REBOL Zen:


How should R2 functions be categorized? They're not really functions 
with vars only temporarely on a stack:

>> c: func [a b] [[a + b]]
>> do c 1 2
== 3

but also not really closures with individual contexts:

>> f: func [a] ['a]       
>> word1: f 1
== a
>> word2: f 2
== a
>> get word1
== 2

p: open tcp://

i: get-modes p  'interfaces
 probe i

 probe i
[make object! [
        name: "if16"
        addr: 91.121.*.*
        netmask: 255.255.255.0
        broadcast: 91.121.*.*
        dest-addr: none
        flags: [broadcast multicast]
    ] make object! [
        name: "lo0"
        addr: 127.0.0.1
        netmask: 255.0.0.0
        broadcast: none
        dest-addr: none
        flags: [multicast loopback]
    ] make object! [
        name: "if16"
        addr: 188.165.*.*
        netmask: 255.255.255.255
        broadcast: 188.165.*.*
        dest-addr: none
        flags: [broadcast multicast]
    ]]

wow, i didn't know u can do that! where is it documented? i just 
remeber get-modes in relation to setting binary mode for the console 
or parity and speed setting for the serial port...

<tab> completion of directories and files works, if you give argument 
as a file! datatype, but not when giving word! argument for CD. I 
believe, this is hard to get by.

Looks like SORT uses this datatype map internally:


[unset! datatype! native! action! function! object! word! set-word! 
get-word! lit-word! refinement! none! logic! integer! decimal! money! 
time! date! char! pair! event! tuple! bitset! string! issue! binary! 
file! email! url! tag! image! block! paren! path! get-path! set-path! 
lit-path! hash! list!]

I don't feel that they should be the other way around. The problem 
is that there is no obvious reason why it should be one way or another, 
so when trying to remember it I get it wrong about half the time. 
Using 'eol would be good, but wouldn't help the problem because we 
can't undefine 'newline in R2 because of the backwards-compatibility 
rules.

You can't get rid of the old name in R2, you can just add new names. 
You have to get rid of the old name to solve the problem.

Get rid of the bad old name and change the few scripts, that might 
use new-line. Problem solved!

I would still like to see a dialected new-lines or line-markers func. 
I don't get the char and func names confused today.

Is there a way to retrieve the name of an object that is referenced 
by another word?
layout  [ a_field: field [ ]  ]
b:  a_field
....
What I want is to somehow get "a_field" given b.

James, in th case of LAYOUT dialect you can get the name this way:

>> b/var
== a_field
>> type? get b/var
== object!

etc.

There is a trick in R3 for variadic functions, but it only works 
for the last arguments of a function, not the first, and only when 
the function is called at the end of the block/paren/script.
>> a: func [x [any-type!]] [type? :x]
>> a
** Script error: a is missing its x argument

>> a: func [:x [any-type!]] [type? :x]
>> a
== unset!

>> a: func ['x [any-type!]] [type? :x]
>> a
== unset!


The trick is to use a lit-word or get-word argument and allow it 
to accept unset! values. This is used mostly for console interactive 
functions like CD.

In R2, the first example would work too:
>> a: func [a [any-type!]] [type? get/any 'a]
>> a
== unset!

But in R3 that behavior is being discouraged on purpose, to make 
code easier to debug, so the alternate argument types are required.

...lit-word and get-word argument...

 - please stop using that misleading terminology. The former is, in 
 fact a "partially evaluated argument", the latter is "unevaluated 
 argument". See the documentation.

Yes, please :-). My todo-list is always getting longer faster than 
I can get rid of it.