AltME groups: search

Parsing reversal does not help IMO, because you have to process both 
left- and right-associativity at the same time

@Endo: I tried exponent with ^, but as it is the escape character 
for rebol, i consistently end up with an error. If enyone can help 
on this! 

For the english comment, I promise I will take the time to translate 
the french comments soon.

hehehe... It has been a long time since I had to implement such a 
challenging problem. It is so fun!

It's tricky to reject a rule later, and PARSE has changed over time, 
so I'm not sure.

(I just don't have time to build you an example... :-p  )

it going thru end would break space-time, so its not allowed by the 
interpreter    ;-)

going thru end would break space-time

 - it is allowed in R3 and there is no reason to break anything, in 
 fact. It is just about the implementation.

to/thru do not match subrules

 - yes, that is a correct observation, although unrelated to the subject 
 of the discussion, and, actually, just a detail of the implementation, 
 that can easily change at any time, especially taking into account 
 the user preferences

Ok, I will. I did long time ago, but maybe it changed, or I missed 
something the first time, or I forgot, how it works!? :-)

Argh, I was confused by sentences like
Where do you think the cursor is after matching the [end] rule?
:-)
Old def. of thru: advance input thru a value or datatype

New def. of thru: scan forward in input for matching rules, advance 
input to tail of the match


Then it can be argued, the tail of end (of a series) is still the 
end. Or it can be argued, that thru always advance some way further 
(as in all cases except at end). I understand, why [thru end] not 
failing is confusing.

(And stop saying, I should read the doc. I have read it ... in full 
this time.) ;-)

I wouldn't call it a trick John, just a non-obvious syntax. I haven't 
used it much, but I wrote a func a long time ago when I needed it 
for something.

literalize-int-rules: func [template /local mark] [
; Turn a single integer value into a quantity-of-one integer
; rule for parse (e.g. 1 becomes 1 1 1, 4 becomes 1 1 4).
	rule: [
		any [
			into rule
			| mark: integer! (insert mark [1 1]) 2 skip 
			| skip
		]
	]
	parse template rule
	template
]

I would be happy to use a function! version of PARSE since i never 
had to do time critical parsing.

When R3's TO and THRU should trigger an error, most of the time they 
just don't match instead, for no apparent reason. There's at least 
one ticket for that.

Having an R2-compatible PARSE that you can run in R3 would be useful 
for large sets of parse rules that you haven't had the time to migrate 
yet.

[any end]and [some end]As we don't have warnings, I suggest these 
to produce errors.


- it is impossible to trigger errors every time an infinite loop 
is encountered
- this case has been discussed and the solution was found already

I liked it at the time, at least the bounded modifier version, but 
of the unimplemented proposals it's not my highest priority.

note that copying the whole thing is probably faster than removing 
multiple times. also, doing several chars at once instead of one 
at a time is faster.

Strange but I tried to remove the whole part in one time, but its 
slower than the other:


aaa: [t: "abc56def7" parse/all t [some [x: some non-digit y: (remove/part 
x y) :x | skip]] head t]

bbb: [t: "abc56def7" parse/all t [some [x: non-digit (remove x) :x 
| skip]] head t]
>> benchmark2 aaa bbb ;(executes block 10'000'000 times.)
Execution time for the #1 job: 0:00:11.719
Execution time for the #2 job: 0:00:11.265
#1 is slower than #2 by factor ~ 1.04030181979583

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.

Making the end-of-line delimiter an option turned out to be really 
tricky, too tricky to be worth it. The code and time overhead from 
just processing the option itself was pretty significant. It would 
be a better idea to make that kind of thing into a separate function 
which requires the delimiters to be specified, or a generator that 
takes a set of delimiters and generates a function to handle that 
specific set.

I don't really need anything but having the ability to parse the 
first 100 lines of a file and doing that many times, so I don't care 
so much about continuation. This is for real-time previews of large 
CSV files (> 10000 lines).

(better response time, when the user abuses import adjustment buttons)

That's fine by me, as I read the file into memory once due to the 
need for one-time UTF-8 conversion, so that will happen outside LOAD-CSV.

I was a little concerned about making /part take two parameters, 
since it doesn't anywhere else, but the only time you need that continuation 
value is when you do /part, and you almost always need it then. Oh 
well, I hope it isn't too confusing :)

As for that TO-ISO-DATE behavior, yes, it's a bug. Surprised I didn't 
know that you can't use /hour, /minute and /second on date! values 
with times in them in R2. It can be fixed by changing the date/hour 
to date/time/hour, etc. I'll update the script on REBOL.org.

I'm working with SQL Server for a long time, if anything I can help 
or test for you, feel free to ask if you need.

BrianH, where did this month-based time table come from? Don't take 
it personally, but I wouldn't trust it, if you don't have enough 
control over it. :-)

Month-based time table: I don't believe it for a second. :-) 2.7.8 
sounds 6 months away to me.

We need that for long time and there's still nothing. I wonder if 
anybody's interested in this project or if everybody's happy with 
the way it is. When yes (everybody's happy now), I can understand 
why the 'outsiders' describe us as "elitists".

I submitted my http patches for 2.7.7 ... and they have yet to be 
reviewed.  Suspect it's a waste of our time.

I assume Edgar doesn't have interest/time to update it?

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.

Add is a complete verb :)  That is why INC and DEC weren't chosen 
at first: REBOL naming standards for built-in functions abhor acronyms 
(ironic) and abbreviations, for the most part (FUNC and FUNCT are 
exceptions). That's why we break out the thesaurus when we want to 
come up with a shorter name, most of the time.

Still, 15 mins seems like a long time.

An invalid pass crack should take ever-increasing authentication 
times... so a 15 min password gen time seems silly.

Well, IMHO, I'd rather spend the time getting DB access generally 
working from R3.

Yeah there is a Rebol/Core 2.5.0.5.2 and a Rebol/View 1.2.1.5.2 for 
BeOS R5. I tried the one with View on the latest nightly build of 
Haiku yesterday, didn't work though, some error message about the 
Media Server Addon IIRC. Could be because I used the GCC4 hybrid 
iso, don't know how far they are with that stuff yet, I haven't followed 
the mailing list for a few months. A R3 port in a few years would 
be good enough for me, Haiku is still in alpha so it's probably a 
good idea to wait a bit more. From what I heard they now have a few 
people working on it full time (paid) thanks to a lot of donations, 
so there is a lot of stuff going on with the Haiku code base right 
now :)

To answer your question, my guess would be time and money. R2 native 
enhancements that RT doesn't need itself need to be funded nowadays.

I pop in, but haven't had much time to code. When I've been here 
lately I'm too exhausted to program.

I'll be on next week, but this is the first time in two weeks that 
I've been able to spend more than a few minutes at home and I'm taking 
a break.

I don't need to see an error all the time :)

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.

When last I heard there was a lot of new stuff ready for release. 
Every time I check there is more, such as the recent graphics fixes. 
Eventually it will be dalayed enough that the stuff that was being 
put off until the next couple releases will be done too. Afaik, 2.7.8 
could have been released a month ago, though the graphics fixes are 
great too.

This is something I do find annoying http://rebol.wik.is/IBM_Cloud/Extend-cloud.r

I have to patch http each time I do any REST stuff

Not yet. Since Thursday, i have had no time to program. Since noone 
has yet posted any links or issues, I'm assuming that there will 
need to be research cheduled for this task first. That can't happen 
until the coming week.

I prefer it always runs as standalone console, even at first time. 
If user wants then he/she can INSTALL or starts DESKTOP.

So I can send rebol.exe to anyone and tell him just drag & drop that 
script file onto that exe file.

my point is that install is very annoying for people who develop 
because it creates a dependency in the interpreter which cannot be 
rooted out.


I am not against the installer, i'm just against it being forced 
upon me, when the whole platform itself has no requirement for it


I have not started REBOL without it requiring an external file or 
socket in what 10 years... so really what is the point.  it just 
makes EVERYTHING complicated, like telling clients they have to fuck 
around with adding -qs all the time in their batch code, etc, etc.

The "copying files to some location" is the least difficult part 
of an installer. The tricky part is determining exacty *where* to 
put stuff. Fortunately, most of that is ahead-of-time research about 
where to look in the registry and environment for settings, where 
to put them, etc. And that varies depending on the Windows version 
because the really good tricks weren't adopted until later.

yes on install time, you have to peek, but not when running.

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 paths change all the time, but where the paths are listed don't 
change. That has been pretty consistent for 10+ years.

Andreas, the installer determines these things at install time, and 
sets things up for the runtime. but the runtime has to look for stuff 
where the installer puts it, and previously R2's runtime looked in 
the wrong places.

right now, when we write REBOL apps, we are running blind.  its very 
complicated, and something most script coders will not put the time 
to learn.

the installer would just setup the values it can find, or leave some 
of these values as run-time functions (some which would rummage registry 
keys, or call routines)

The biggest problem with /View on Windows is that it puts its runtime 
settings in the wrong place, almost every time. Global stuff in user-specific 
places, user-specific stuff in global places.

in my app, I ended up doing all URL manipulation in strings, and 
then just converting to url at the time of network call

A good look will be possible for R3 to do. It's simply a waste of 
time for R2 and you can't produce anything that resembles Aqua anyway 
in R2. In R3 that is possible. But focusing on look alone is a big 
mistake, which too many developers using GUI systems are suffering 
under.

2.7.8 turned out to have to be a minimal release, due to outside 
constraints. That means it's time to talk about 2.7.9.

2.7.7 also turned out to have to be a minimal release at the time. 
It's hard to budget time for major native changes in R2, partly due 
to business constraints (who is paying for this work? noone that 
I know of, and adding Library to Core removes a revenue source without 
replacing it with another), and partly due to the nature of the codebase 
itself.

Diffs from the old preliminary changes doc to the actual 2.7.8 release 
(that I know about):

- No installer changes yet (my bad, I didn't have time to do them)
- SINGLE? is LAST? instead
- RESOLVE is a (slow) mezzanine for now, not native

- Don't know about what the Command boot problem was or whether it 
was fixed
- No HTTP fixes yet
- No X fixes yet

- ASSERT and APPLY are still mezzanine, and ASSERT is still rather 
bad
- No FOREACH setword support yet
- SET-ENV native (with limits)
- Delay sound subtask creation (whatever that means)
- RUN function uses 'shell access in SECURE
- FIND and SELECT on objects
- FUNCT /extern option, SPEED? and DT

- Some fixes to bugs in RAMBO that I don't know since RAMBO is down

Carl was glad with the compliments on 2.7.8, but likewise, I seem 
to be the one who will have to promote R3 on OSNews in the time to 
come, and I can't do that if I don't believe in it

Graham, I sometimes see the copy  problem happening. I'm not sure 
why it happens and I am usually running rebol. Mostly I notice it 
with Ultraedit and Altme though I think they become the victims of 
the circumstance. I'll notate it more closely when it happens the 
next time. BTW, paste always seems to work but it will of course 
paste the last thing it could copy.

In particular, they block all apps not in their whitelist any time 
a "secured" web browser is open.

Yes, it was to search for viruses but I think it was because there 
was a particular flurry of some viruses at that time so I thought 
it would be easy enough to add ...

we shifted the time schedlue

Nenad skis the usual jokes out of time pressure

-- type mismatches caught at compile-time instead of runtime

Material and links will be published over time when they become available

Hi guys, I've spent a great time at the conference (and after also) 
with the people present. A big thank to Bas and Kaj for organizing 
this event, it was really nice meeting you all (pity that Robert 
couldn't been there to present RMA's GUI). The Boron's OpenGL demo 
was impressive (Star Trek's Enterprise ship), I'm looking forward 
to see the dialect used for that.


 I'm currently preparing the slides I've presented to put them online. 
 Should be done in the next hour.

With the big wave coming in front of the boat, I'm not sure you'll 
have the time to wait.

The last time i looked at Paul Graham's arc, that seemed to be stalled 
as well.  the point is that this is a huge undertaking for any single 
person

the last time there was a language fork .. RT made some announcements 
to try and make rebol more attractive

Ladislav - what are you talking about here? What is decent and constructive 
about the conference name? Are we going to be censored here, or what? 
This is really starting to be crazy. Look at the Amiga - there is 
AmigaOS, Aros, MorphOS, UAE, there was Amithlon .... and I expect 
ppl meeting at various accassions, to share the spirit of the Amiga, 
although there were some infights between the groups.


Now to REBOL. Last DevCon (Italian Devcon was not even called RebCon 
- http://www.colellachiara.com/devcon05/) was held in 2007 in Paris? 
Then there was one online meeting coordinated by Nick (?), and there 
was an attempt to organise DevCon in Prague, in two consecutive years. 
Carl decided not to attend, from various reasons, so we decided not 
to push the idea of the conference forward.


Then I remember the chat of the community about the topic, thinking 
about organising some REBOL related conference in Amsterodam, simply 
to allow ppl to meet, not necessarily being dependant upon RT attending 
the conference.


And now guys organised ReborCon. I know it was initially related 
to Syllable, and REBOL clones. But - if you read the website carefully, 
the topics are much broader - it already mentions topics for R2, 
R3, Boron, Red. So - what is the problem here? To abandon non official 
REBOL topics on conference, which is called RebCon, because somehow 
imaginary, RT might have the right to "own" the conference name?


Shouldn't we be in fact gratefull, that Doc did not abandon REBOL 
ultimately, but starts his own project he believes in, which in the 
end can benefit for both sides - Red and R3? Is there really NO right 
for me to even not suggest a possible conference name?


The Rebcon conference name was just first out-of-my-head suggestion. 
I can come-up with some others - ReClone, ReCon, or even ReDCon (Rebol 
Developers Conference), and if you give me some time, I might come 
with something even more sophisticated marketing-wise ...

It fell off the wagon due to lack of time. That's why we've already 
planned another conference

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

Yep, not much time left to accomplish something...

The first A is defined inside MY-CODE-A block. And because you do 
not use copy [], it's not rewritten every time you call MY-CODE-A 
block.

What is more curious in the "You set the word a to refer to the block 
defined in my-code-a" is the word "defined". The truth is, that MY-CODE-A 
is a block, that is created by the LOAD function at (roughly) the 
same time its contents, including the above mentioned subblock, come 
into existence.

probe load %/c/cheyenne/www/makework/data/wf001.txt
[make object! [
        id: 'wf001
        name: "Add Work"
        node-map: [make object! [
                id: 'SOURCE
                Description: "Add new software for Site"
                status: 'Complete
                Next-Node: 'A
                sub-tasks: "1. Used RFA to enter."
                When-completed: []
                Time: 60
                Notify: none
                status-url: func [] [

                    join http://localhost/makework/status.rsp?id=ID
                ]
                action-url: none
                mark-complete: func [] [
                    Status: 'Complete
                ]
            ] make object! [ ....

Onetom, that error has been reported already and fixed in R2/Forward, 
but it hasn't made it into R2 yet. Here is the revised MAP-EACH:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

LOL, well, I remember I have been bitten by this many years ago so 
from that time I'm using it according to the help ;)

One of the tricks when refining the details is to realize that there 
is a real runtime difference between recommending that people not 
do something, and prohibiting something. Every time we prohibit something 
it has runtime overhead to enforce that prohibition. So every recommendation 
needs documenting and explaining, but every prohibition needs justifying. 
There are situational tradeoffs that recommendations can resolve 
easier than prohibitions. This is why we have to be extra careful 
about this.

Actually, that's still considered pretty simple. You still might 
need a DFA for some of the rules, but most of them can be recognized 
by hand-written code more efficiently. The problems are not caused 
by not using a generated lexer - even a generated lexer can have 
precedence errors. The real syntax bugs in R3 are there because noone 
has really gone through and figured out what they are, systematically; 
most of them are still undocumented. Recently, in my spare time, 
I've been trying to go through and document the syntax and ticket 
the bugs, so soon the limit will be developer time. (In R2, the bugs 
are there because the syntax is frozen for backwards compatibility.)

We keep adding more points of none propagation, and every time we 
add one it makes more errors propagate further away from their point 
of origin. This makes it harder to figure out which code caused the 
error where none wasn't screened for or checked for, making it that 
much more difficult to debug.

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?

But that doesn't work when you don't want a time and date.

>> d: now/date
== 14-May-2011
>> d: now d/time: none d
== 14-May-2011

In some SQL implementations, date, time and datetime are different. 
And then timestamp is different from all of those.

A TO-DATETIME function would be great. GMT by default, or local time 
like the rest of REBOL?

In R3, GMT seems to be the default time zone. Interesting.

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.

to-datetime: func ["Converts to date! value." value][

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

and just a refinement to default to local time

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.

So, what do you suggest?

>> d: 15-may-2011/12:00:00.00
== 15-May-2011/12:00
>> d/time
== 12:00

I think I'd like to see a flag or something that sets the number 
of decimal places for decimals, and number of places for time.

Having something that changes the display depending on what time 
it is ... is ... annoying

if it's a date with no time portion, then date/date gives you an 
error.


It works for me. Or maybe I'm doing it differently. A date! always 
has a time value, correct, though it may be none? And if it's none, 
that affects the default formatting.


While I've had a few times that the trimming of zeros from time values 
annoyed me, it isn't high on my priority list. If I don't like REBOL's 
default format, or if I have to send data to another process, I just 
know I need to format it.

FIRST, SECOND and THIRD can be used on functions like:

>> first :repend
== [series value /only]


SECOND and THIRD returns the function body and spec. FIRST returns 
a stripped spec, just the arguments and refinements. I notice, it's 
produced each time contrary to the other two:

>> same? second :repend second :repend
== true
>> same? third :repend third :repend  
== true
>> same? first :repend first :repend
== false


What is FIRST on a function used for? It may be used internally, 
but does anybody use it externally? It seems more logical, if FIRST 
on a function returned the spec, SECOND the body, and nothing else.

I see, they're all produced each time in R3:

>> same? reflect :repend 'spec reflect :repend 'spec
== false

Guess the R3 implementation is better in this case.