AltME groups: search

You might as well not fix any bugs at all becuase Windows is not 
a very stable platform

Ask Carl to produce a port to Wine ...

Look, I´m not interested in a philosophical discussion. We waited 
three years to test R3 and now we´re asked to report bugs ASAP. What´s 
the point of fighting it?

But what bugs are you reporting?  A bug with wine??

A bug in running R3 on Linux

The point is that previous experience with Wine shows it is not a 
stable platform to test on. That's why there is a discussion.

As I said, previous experience shows Windows is not a stable platform. 
What´s the point of any software development at all?

If it´s this difficult to report a bug, then I will refrain from 
it

Graham, an issue with 100% CPU usage every time a GUI was invoked.

So,it was a wine issue?

uh, on Vista and R2 I get:

>> dir? %work
== true
>> dir? %work/
== true
>> file? %work
== true
>> file? %work/
== true


Is that correct? :-) There is a work directory on my system, so how 
is that "file? %work/ reports true?

Isn't a directory also a file?

Kaj, I understand it's very frustrating only to be able to do limited 
testing. Being on OSX, I have to waste a lot of resources running 
WinXP in VMWare to test R3. I think it's a good idea to keep some 
talks going with the Wine people to make sure and verify that it's 
a Wine bug rather than an R3 bug. This is in order to keep Wine out 
of Carl's hair, so to speak, so he can continue development of R3 
as rapidly as possible. I deeply respect the daunting task it is 
to emulate the Windows API and I would not like to be in their shoes.

We just need to understand how it operates in R3.  It's more of an 
adjustment in our thinking than a problem.

Is it normal in R3 to get a bunch of output in the console when saving 
a file?  save %blah "test"

yes, that is for two reasons. when saving a file, a port is returned, 
which was not the case before. the other reason is that objects are 
now returned to the console.

Switching from AltME to RebDev chat has been very hard for me and 
since I am not a core developer I will be in read only mode until 
the GUI version will be released.

However I am not negative about how things are going. We finally 
have a pubblic alpha. an upgrade mechanism, an internal chat system. 
GUI is going to be developed and also documentation reviewed.

I'm not a fan of rebdev either but I view it as the catalyst for 
the GUI side of it.

However we are in the middle of a big change. Once the new messaging 
system and the GUI will be complete the whole speed of REBOL3 will 
shift up again.

Expect a 2 months where everyone involved will work in the cavern 
with Carl and then we will finally have something to start with seriously.

March is fine for me.  About that time I really expect my project 
to be in a mature state via 2.7.6 and can then hopefully begin porting 
at that time.

By now, we could only try to test REBOL3 and report bugs in CureCode. 
It is still a big thing.

For discussion with the development team we need to use the chat 
system as everything else (AltME) seems abandoned.

Lets not forget it is a complete new beginning. While R2 is a mature 
man R3 is still an infant.

It is nice to see lot of interest around it. This mean that the child 
will be well supported by an extended family of relatives ;-)

It doesn't matter that WINE is not a stable platform to test on - 
it's fixable, whereas Windows is not. We will try to make things 
work.

However, native support for R3 on Linux and other WINE platforms 
will continue to be a higher priority than WINE support.

Graham, if you want to form file paths without checking whether the 
directory portion has a trailing #"/" do this:
    blah: %dir
    f: blah/(file)
instead of
    f: join blah file

I use that trick with these a lot:
    .: %./
    ..: %../
then you can do this:
    read ../blah.r

GiuseppeC, I think that from a /core perspective that R3 is more 
mature than R2.

An include function is really unlikely because of binding issues, 
unless that function only returns a module reference and doesn't 
rebind the calling context with its exports. Binding order matters 
in REBOL.

There is now a WINE platform choosable in CureCode.

Done. Here is the R3 and R2 FILEIZE:

fileize: func [
	{Returns a copy of the path turned into a non-directory.}
	path [file! string! url!]
][
	path: copy path
	if #"/" = last path [clear back tail path]
	path
]

Here is the R3 DIR-EXISTS? and FILE-EXISTS?:

dir-exists?: func [
	"Returns TRUE if a file or URL exists and is a directory."
	target [file! url!]
][
	if #"/" <> last target [target: append copy target #"/"]
	'dir = select attempt [query target] 'type
]

file-exists?: func [
	"Returns TRUE if a file or URL exists and is not a directory."
	target [file! url!]
][
	if #"/" = last target [target: head clear back tail copy target]
	'file = select attempt [query target] 'type
]

Here is the R2 DIR-EXISTS? and FILE-EXISTS?:

dir-exists?: func [
	"Returns TRUE if a file or URL exists and is a directory."
	target [file! url!]
][
	if #"/" <> last target [target: append copy target #"/"]
	found? all [
		target: attempt [info? target]
		'directory = get in target 'type
	]
]

file-exists?: func [
	"Returns TRUE if a file or URL exists and is not a directory."
	target [file! url!]
][
	if #"/" = last target [target: head clear back tail copy target]
	found? all [
		target: attempt [info? target]
		'file = get in target 'type
	]
]

Brian, what is the replacement for get-modes in R3?  I'm want to 
see if I can now set creation and modification dates on directories 
yet.  (see if it is now fixed in R3).  I had to scrap a project before 
because of this.

why do we need special exists functions, when file is a datatype? 
Gee, I hate all those read-* - they are proof there is something 
wrong ...

I have just taken a look at the DEMO and it is really amazing. Things 
are done in few lines of code. I feel the power.

We are now again in a grey area ;-)

USING: string math http ;

: plus ( a b -- c ) + ;

USE: vectors

: vec-plus ( a b -- c ) + ;

what I really liked about this (I am not a specialist in factor so 
I hope I am not saying it wrong) but when I was making DB libraray 
for example I could use define very generic words like SELECT WHERE 
UPDATE without thinking if they are defined somewhere else.

I am sort of factor traitor :( ... I was doing a very important project 
for me in it and told everyone that I am doing it etc... got relatively 
far, but then by "accident" discovered that there are many practical 
reasons to switch that project to Rebol, so I abandoned factor :/

Links to web sites would be nice. I suspect that REBOL's situation 
is a little different though, as the binding model is unusual.

technology is a cruel world :) "at the end, there can be only one"

I can understand your choice, Rebol is a good alternative, even if 
I Factor is a very interesting langage to study.

it's a forth + lisp + haskell sort of language .. it's stack and 
image based

kib2: yes .. both are interesting ... I had a bunch of concrete reasons 
to switch.. basically I didn't want to, but all the indicators were 
in favor of rebol for what I need (I intend to write a blogpost about 
it .. because it's too long to explain here)

The particular binding order effect that matters in REBOL is that 
"outer" and "inner" scopes are faked with the binding order. Any 
attempts to revise the "inherited" contexts that the code is supposed 
to have, after the code has started running, is unpredictable at 
best and crashworthy at worst - a bad idea in any case. This means 
that if you want to import words from other modules into your code, 
you should do it *before* your code starts running. This means import 
headers, not import funcctions.

I don't have a good view into what "binding" is at rebol yet .. I 
imagine a little

kib2 : nothing was really missing in factor ... I live from my coding 
so I have to choose the tools where I think I will fasters with least 
problems and best solve what I need... this was a web-app that needed 
to run on desktop to (so all apache+ XX + mysql) fell of and it gave 
me a reason to make it with factor.

but as I said, it's complicated a little ... I can copy paste you 
the text I wrote to dockimbel when I was explaining him how I started 
with cheyenne few weeks back..

>>>basically I tried cheyenne and rebol for web-apps just by accident 
... one saturday I was ready to work on that project in factor whole 
day and then some hard bug in factor server prevented me from working, 
so because I was in a working mode I started playing with doing some 
other simple idea in ruby on rails (I haven't tried it yet before 
- I don't like frameworks in general) .. after I hit some magic of 
RoR I stopped and then tried cheyenne RSP .. and I made a basis of 
a working app in that afternoon ..  when I tested and saw it also 
performs I was hooked..<<<

in short: Factor is very interesting language but I was amazed at 
how productive I was with rebol + rsp, I need PDF: factor has some 
deprecated bindings to c lib for generating pdf-s, rebol has a dialect 
for that, I need to run in on a desktop standalone: factor can run 
standalone but is more heavyweight, cheyenne server starts and shows 
icon in tray "before I even click it" , I need a tray icon too for 
my app, I found example of it already and it works, in factor something 
like this doesn't exist yet ..

and bottom line is the language , rebol nicely scales al the vay 
from newbie (imagine VB coder) up to advanced user with introspection 
code is data and all , factor is a little more scarry to start with

Janko: the pdf and postscript dialects in Rebol have impressed me 
a lot. Maybe it's possible to build something like LaTeX in Rebol.

Janko: I'm not a Factor expert (I started studying it 3 weeks ago). 
But the Factor learning curve is certainly higher than Rebol's one! 
Sometimes I have hard times remembering what's on my stack when I 
try to write non-trivial words.

( + if I will need gui for desktop server, rebol has lighweight software 
rendered gui, factor also has a gui but on windows it's opengl based 
which is not really practical for a gui.. even casual games on windows 
try to use DX7 renderer for maximum compatibitily and avoid opengl 
beacause of driver issues)

Like I said, many implementations. The lead author is currently making 
a new version written in C++.

Factor has very reactive/alive comunity... they make bindings to 
a lot of stuff quickly thats why I prefer it.. they have everything 
from web-server/web framework to opengl stuff, etc

The original implementation also runs on Mono if you are a purist.

I am not a purist , but if I see something .NET / Mono .. I am not 
that interested, but I see now that it has many implementaitons yes

(just btw.. factor is compiled, slava also posted a lot of info about 
how he compiles and optimizes the code etc ..  this is his talk I 
mentioned: http://www.youtube.com/watch?v=f_0QlhYlS8g)

BrianH: in this case, don't call them programmers. A programmer is 
curious, and likes to think differently by nature!

never mind, I forgot to type the user name. :-) it's been a long 
time since I last had to log in.

Basically the same as a year ago, but it includes RebDev now

Janko;  It you are diving into Cheyenne RSP, make sure you give QuarterMaster 
a look see.  http://www.ross-gill.com/QM/

Chris, like Nenad, is counted among the unsung heroes of the world, 
in my humble opinion.

btiffin: thanks for letting me know, I was checking out QM a little 
and Chris has helped me few times here already... but about the frameworks.. 
I don't like to use (mvc) frameworks , in any language

Just did, and they look related. I think MAKE IMAGE! is hosed - it's 
probably a good thing we don't have LOAD-JPEG at this point.

As an alternative to DIR-EXISTS? and FILE-EXISTS? we could change 
EXISTS? so it returns more information.

; R3 version:
exists?: func [

    "If a file or URL exists returns 'file or 'dir, otherwise none."
    target [file! url!]
][
    select attempt [query target] 'type
]

; R2 version:
exists?: func [

    "If a file or URL exists returns 'file or 'dir, otherwise none."
    target [file! url!]
][
    unless error? try [
        target: make port! target
        query target
    ] [

        either 'directory = target/status ['dir] [target/status] ; To work 
        around a current incompatibility
    ]
]


EXISTS? could still be used in conditional code, with the exception 
of AND and OR, but would have more info if you need it.

I've almost never seen EXISTS? used with AND or OR, though I rarely 
see AND or OR anyways. You can always use FOUND? or TRUE? if you 
want to turn it into a logic value :)

There are a couple *? funcs that don't return logic!, but the trailing 
? nearly always indicates a simple predicate. I can see how this 
might be useful, but also how it could trip you up. I can't complain 
too much though, since I've written my own *? mezzanines that don't 
return logic!.

Well, we really need the information returned by the EXISTS? function 
above, and my last attempt to get that information out in a R2-R3 
compatible way (the above *-EXISTS? functions) got a lot of complaints 
(mostly from Gregg, as I recall). This is hopefully a less annoying 
change, and is compatible now even without the 'dir tweak if you 
check against 'file instead.


My opinion of the *? functions that are meant to be predicates is 
that they should be usable as predicates, but don't necessarily need 
to be simple predicates. As long as you can use them in IF statements, 
they're fine. We have methods to convert from REBOL truth values 
to logic! if we need to.

Sure. In REBOL 2 there are 2 functions, EXISTS? and DIR?, that check 
for whether a file! refers to an existing file and whether the existing 
file is a directory, respectively. Both of these functions wrap around 
QUERY, a low-level native that works very differently between R2 
and R3, mostly because of the port model change. In addition, DIR? 
has a design shortcoming in R2 (mentioned in CureCode ticket #602) 
and both DIR? and EXISTS? share the same bug in QUERY in R3 (#606, 
affects #602 and #604).

All of these combine into a few problems:

- People who want to write file and directory management code that 
is portable between R2 and R3 have trouble doing so.

- Bugs of the kind mentioned in #602 are not likely to be fixed in 
R2, so we have to consider DIR? broken for non-existing directories.

- Using both DIR? and EXISTS? means two QUERY calls, which has overhead, 
particularly for networked files.

- Attempts to get around this using QUERY require completely different 
code in R2 and R3, so wrappers would be nice.


As it specifically relates to 2.7.6, for people who don't care about 
forwards compatibility, there is only one problem:
>> DIR? %nonexistingdirectory/
== false  ; Should be true, unlikely to change

Also, R2 and R3 could use a standard function that does the opposite 
of DIRIZE. Current proposed names are UNDIRIZE or FILEIZE.

>> a: %directory/
== %directory/
>> trim/with a "/"
== %directory

I sure hope all these mezzanines don't get distributed with REBOL. 
 Because even if they are still distributed as a package with the 
main bin then it is still bloat.

Rather, there be a separate distribution for just the main bin and 
then the mezzaines.

Seems were getting to many mezzaines for simply tasks.  Were gonna 
be a laughing stock.  LOL.

don't take that seriously - after all I run a mezzanine thread on 
my site.

We only include the mezzanines we use, and I wouldn't suggest something 
unless there is already a need for it. Your TRIM/with code is wrong, 
btw, we only trim the last / and from a copy at that.

R3 will be less bloated than R2, but you are still missing something: 
you say "the main bin" which assumes that R3 will be distributed 
in a single monolithic binary like it is in R2. Not doing that is 
the reason for the split of the host code. Build your own monolith 
if you like, including whatever functions you need.

Think of these as a standard library of helper functions that you 
don't have to use if you don't need to. If you do use them, you can 
count on them working as correctly as the REBOL experts can make 
them work, and as efficiently. Either way REBOL is better.

Yes Brian, but the two exists functions above are necessary because 
a change has been made to the operation of query.  In those cases 
it is necessary to modify mezzanines.

Yeah, I understand the point behind mezzanines which is why I maintain 
a good quantity of them outside of the REBOL distribution.

I posted it above as FILEIZE, but here:

undirize: func [
	{Returns a copy of the path with any trailing "/" removed.}
	path [file! string! url!]
][
	path: copy path
	if #"/" = last path [clear back tail path]
	path
]

head clear back tail is much faster than reverse remove reverse. 
All of that reversing is series copying, as is remove from the head 
of a series. If you don't need your function to copy, change reverse 
remove reverse to clear back tail.

Yup :). Also, the return value of mine matters, as it does with DIRIZE, 
while yours is tossed. You wouldn't be able to use yours as a swap-in 
replacement for DIRIZE for non-dirs. Mine is a function, while yours 
is more of a procedure (making the Pascal distinction).

If you add a file on the end of the function you would have a useful 
return value. Then the only difference would be the copying.

That would be the same with both. Well, remove is easier to undeerstand 
than clear, so it's a good choice.

Clear might have a lot of underlying code for ports use as well which 
may be the reason why remove is better.

I ran a dozen profiles of each, and they were 50/50 on which was 
faster. That is well within the profiler variance.

I submitted a tweak to dp that improves the accuracy, but the profiler 
is too inconsistent to time differences this small well enough.

For instance, that /into proposal was based on huge differences picked 
up by the profiler. If implemented it could eventually lead to user-visible 
reductions in overhead. That's a big deal.

Well, my get-block function is an example.  I used it on a series 
of block data and get different results that don't seem to jive with 
my expectations.

I had done a test where I read a small 5000 record file and compared 
to a 100000 record file and the 100000 record file proviled better 
performance than the smaller one.

Sounds like cache is a factor here.

Cache is definately a factor in those type of operations.

I know how to move in it but it is just a pain compared to alternate 
methods.

Evals could be improved dramatically to be a very cool function.

Well in a sense ALTME has as much threading as RebDev by the means 
of groups.

I still think a better solution would be a darknet forum that way 
Carl doesn't have to worry about spammers.

Assuming 'dirize asserts a state on a file (dirized or not).

Always think of the impact of a function regardless of size when 
it is done in a large loop.  All of those extra checks add up.