AltME groups: search

I have submitted a feedback to 'AltMe'... and doing a search on RAMBO 
to see if there is an entry for this as well.

IMO View OS wrapper should be strenghtened in general. It would not 
hurt to properly detect two monitors or TV output, if possible. I 
can see that MANY apps get it incorrectly, e.g. they simply call 
center-screen or such a function, and half of the dialog box is on 
one string, the other half is on second one :-)

I only have to change it when I use a new world, so I always forget 
that. I think I've mentioned before that it's a poor UI layout for 
that.

Is possible to start an altme world server  from a non-graphical 
enviroment  like the linux shell

Sadly no, this is a deep issue with Rebol/Linux/Fonts

Are the problems with scrolling on Windows a Rebol/View problem or 
an AltME problem? 

I don't seem to get the problem on Linux.

Is it possible to start AltMe so that it will start a preset world?

Is it possible configure AltMe so that private groups are visible 
only to group members ? Currently they a visible for all.

Is it possible to start AltMe so that it will start a preset world?
 -yes: "C:\Program Files\altme\altme.exe" -w "Rebol3"

So that is why I think product like Altissimo (mixture of IOS/Altme 
- platform for sw delivery) could still be a winner, even if IOS 
is dead for few years already ...

qtask page is loading 16 seconds here (I've got >8MBit/sec line, 
so this should not be a problem) - so that's the feeling. I like 
it very much, but REBOL front-end would be better I think. I also 
understand that web interface is necessity. It's just that 16 seconds... 
:/

A style a day keeps the doctor away.

Qtask with a rebol front-end requires a fairly advanced rebol GUI.

Anton, I see managing styles on the canvas as the challenge -- we 
lack a killer dynamic layout engine.

Chris - what is the main difference between a web-launch and plug-in 
aproach? Isn't plug-in a better deployment way?

Web-launch was an idea I'd posted here (another group) about a browser 
interpreting a Rebol script, then presenting metadata and a large 
icon to launch the script.  I don't think the plugin is better.  
It's right in some situations, but I'd prefer in most cases to launch 
my reblet.  I may change that opinion if the Rebol plugin were as 
seamless, if not as ubiquitous, as the Flash plugin.

hum  strangely the apache group suddenly became red and a mesg dated 
from august came in !? strange.

I rebooted my machine... a laptop I rarely need to reboot.

No such luck for me - still 53 empty conversations on my Windows/XP 
installation. Though I guess most of them haven't had a post for 
a long,  long time.

Isn't the recycle crash a thing of the past?

Setting to a large number does make switching between groups tediously 
slow.

I'd like to think it is a thing of the past...But as far as I know 
all we applied was the low-count workaround.

The main feature that needs to be added to AltME is prevention of 
a post being lost if the Internet connect happens to be broken.  
This happens often for me as the phone lines here are very unreliable. 
The user should be able to work off-line, and his post automatically 
be sent when he log on.

When I want to send a longish post, I write it with my preferred 
editor and then I just copy it to here.)

(my TFUNC does this "more comfortably" and for REBOL3 a change in 
that direction is planned)

(do you really want me to present a formula here?)

Then they should be loadable, shouldn't they ? There will inevitably 
be a case where they are needed in a program.

every Decimal! is "molded differently" somehow, no decimal is "exactly 
molded", example: 0.1 is a decimal! , but because the decimal! values 
are IEEE754 binary floating point, 0.1 is represented as the nearest 
IEEE754 number, which is not 0.1, because IEEE754 cannot represent 
0.1 as you probably know

That means the decimal! maximum needs to be pulled back to the highest 
value which does not cause a problem.

the solution is not that easy. The problem is, that if somebody gives 
a number that is higher than all representable numbers, the overflow 
*should* occur. so we may need higher accuracy instead

Ok, I suppose you asked this poll question because you are looking 
for a way for the highest decimal! to be load moldable and it looks 
difficult / problematic.

The trouble is, that the 16-th and 17-th digits are a bit "nonsensical", 
but they are needed for this purpose

Another idea is that both MOLD and FORM give 17 digits, and it is 
left to another function (perhaps a FORMAT mezz) to cut off the nonsensical 
digits.

Ladislav you are hitting the Serialization/Marshalling barrier. Having 
a language where there is no difference between serialized (molded 
in rebol terms) types and source code types is big plus of Rebol. 
But on the other hand it limits you when you want to marshall the 
data becuase of the assymetry introduce to maintain accuracy for 
some types like decimal.

IMO non-loadable things should not be moldable. So in this case make 
limits on mold, so that the mold fails with such values. Reason: 
IMO under no circumstances should a save destroy values (at least 
not from the inbuild side). Better throw the last changes away with 
a "cant save, internal error" than overwrite valid data with broken 
one. Specially if rebol is a "public" format like xml, where everyone 
can send data and trigger a broken save.

Volker:the console has got a problem with non-moldable value (it 
tries to mold every result)

On further thought, I think the decision to use binary floating point 
numbers in one's program is a decision which includes the understanding 
that there will be some molding inaccuracies. Whether you try to 
print all the digits including the nonsensical final digits (which 
is inconvenient for most usage), or try to hide them (moving the 
problem to load/mold non-orthgonality), either way you must accept 
a problem.

Unfortunately, we currently don't have a non-binary alternative floating 
point type.

What I'm trying to say is: I would be happy for the current molding 
of decimal! to remain as it is, if I had a deci! type that I could 
use instead.

LAdislav: Fix the console. Or at least a check 'reloadable? , which 
as meazzine molds, loads and checks for equality, and without to 
much overhead.

default should be "better error than sorry" for 'save-related things 
IMHO, a dont-bother option would be ok.

I am very sensitive with save since people learn "save often" to 
keep their data, well, safe. Calling something "save" which breaks 
happily data was totally unexpected to me when i started (in the 
times when even a "}" in a string meant trouble, much bette rnow)

I wrote this a long time ago, but it should still be useful:

Anton, thanks. I get it. You have to "turn on" the feature then use 
system/script/args with a "do/args script.r"   Thanks.

If rebol used unicode for source code the problem with deci! could 
be address in the same way that plt-scheme does. That is they just 
have exact and inexact numbers. Exact numbers print all digits up 
to the precision in a normal way. Inexact values print the number 
and the last digit has a dash on top. Operations of exact with inexact 
yield inexact. If the programer wants to warrant exactness he converst 
from inexact to exact, which just means removing a flag and assumming 
the number is exact to the number of digits given.

I know that due to efficient represeantion of values with 16bytes 
gives a constraint. But it would be really cool if rebol adopted 
the tower of numbers from Scheme.

Rebol offers a way for handling molding of new data types that could 
be exploited. We could mold an inexact deci! using something like 
#[deci! [precision: 4  value: 1.33333333]]

...the problem with deci! could be address in the same way that plt-scheme 
does...

  - there is no problem with deci!, it is decimal! that has got a problem

I take "either is fine" as a possible answer too

The break/return should only change that with a 
  f: func[[throw] x] 
IMO.

I think this is a bug ...

what's the easiest equivalent to:

>> set to-path [a b c] 7 ; doesn't work

where the block may be a set of arbitrary words in an arbitrary object.

>> a: context [b: context [c: 0]]
>> a/b/c
== 0
>> set-path [a b c] 7
== 7
>> a/b/c
== 7

wow, that's a lot of stuff alright...

do reduce [to set-path! [a b c] 7]

yes, the word 'a must have proper context for this to work

do reduce bind [to set-path! [a b c] 7] 'a does not seem to work

do reduce bind [to set-path! [a b c] 7] 'a does not seem to work

 - right, that is not supposed to do anything meaningful, it simply 
 keeps the context the word 'a had

>> a: context [b: context [c: 0]]
>> do reduce [to set-path! [a b c] 7]
== 7
>> a/b/c
== 7

If 'a does not have meaningful context, then bind [...] 'a cannot 
repair the situation

but 'a does have a meaningful context. I'll have to try a different 
approach.

You shouldn't have to do that (load mold). Can we see a bit more 
of your code ?

it's only a small part of the function

I'm rewriting my relations engine, if you remember that one.


I need to traverse rel-obj via paths, so I store the path as words 
in a block. This is in order to maintain the current position in 
a deep object.


The input can be any arbitrary path of words and values. If the values 
or words don't exist, they will be created on the fly. That's what 
I use 'p for.

the code with the do load mold... is supposed to insert a new object 
at the path position if the current value at that point is 'none. 
I removed some of that "if none?" logic for clarity.

the rules and structure is completely arbitrary, which is one of 
the stronger points of the relations engine.

however the current version forces you to use a path block structure 
of [word value word value word value...] which forces you to choose 
a value that will not be used for branches where only one path should 
exist. that's why I'm doing a rewrite.

>> a: make object! []
>> b: make a [new: none]
>> same? a b
== false

I think you might have found a bug. I see something which I find 
hard to explain:

>> obj: none
== none
>> path: [obj]
== [obj]
>> code: reduce [to-set-path path 'make to-path path [new: 123]]
== [obj: make obj [new: 123]]
>> print code/1/1 = 'obj
true
>> ?? code
code: [obj: make obj [new: 123]]
== [obj: make obj [new: 123]]
>> do code
== none ; <-- what a strange result !
>> ?? obj
obj: none

a path with only one element is probably not supported.

isn't a path with one element pretty useless then? I just wish that 
set would work on paths. it makes sense to me.

a path with one element is useless indeed. you cannot create it normally; 
it's like words with a space, or issues with a space, and so on. 
they exist, but they are not "valid" in a strict sense.

I see the problem.  A path can represent different things, so if 
your path is not representing anything yet, then REBOL won't know 
how to deal with it as opposed to setting a word with 'set.

No, wait a minute, this code is what I meant (just changes the first 
line):

OBJ seems not to have been changed by doing the code.

Gabriele has seen that a set-path! with only one element doesn't 
work, but you can use a set-word! instead, because they're conceptually 
the same, and they look the same:
>> to-set-path path
== obj:
>> to-set-word path/1
== obj:

Hmm.. I think I agree with Gabriele - the path with one element molds 
just like a word, so it would not load back correctly. Mold/all could 
be made to handle 1-element paths specially, writing the datatype 
eg:  #[path! [obj]]  Is it worth it, though ?

well, it does seem to work, but it's only the first step of a few 
more. I hope it'll be worth it :-)

so it's not a one-element-path problem but a "simple" issue of binding 
the path to the right context.

BTW you can manipulate a path like a block. And it may help to use 
'in.

%/C/ actually has more than one element. %/ only has one element, 
in the file sense, but it also has a special meaning. A path with 
one element is just a value, most likely a word.

%/C/ is a file! not a path!
A file! is a string type.

the first element of a path! must be a word! (i'm not aware of any 
other ways to build a path, except for using make path! directly), 
and there must be a second element.

:) I understand Brian, it was just my first retort. :) Of course, 
a 1-element path! would be indistinguishable from a word!

I'm trying to log into an FTP server with \ in the user name. Is 
that legal to use? I've tried a few different clients and only Total 
Commander will accept it. Rebol will not accept it as a valid URL, 
unless the \ is removed.


The problem is that the webhost Talkactive apparently use \ in all 
their usernames...

that's a bit of a problem

is this in RAMBO or not generally something that would be considered 
a good idea?

well, it's a problem if you want to access certain webhosts, then...

if \ breaks something in the URL parser, then it would be a problem 
of course, but then again, you can't rely that much on the FTP system 
in rebol

I prefer out-of the box functionality, and not a strick adhering 
to standards, if the usage is pretty common ...

That's a problem with FTP in general. There are some servers which 
break the standard (which is also open to interpretation in some 
areas). RT's url parser is doing the correct thing, but supporting 
FTP in the real-world means also dealing with "rogue" standard-breaking 
servers. You could argue that if RT includes FTP in the language 
they should go the whole way with it to prevent dashed expectations. 
On the other hand, you can see rebol is more about breaking with 
the past and coming up with new, more modern (and hopefully more 
reliable) protocols. (Of course, it is possible to have both.)

So, I expect there to be a number of servers supported by FTP-Gadget.

henrik, use a block, not a url, i.e. open [scheme: 'ftp user: "\\\" 
...]

is it faster to load a string to see if it is a date, or try make 
date! and catch the error to peform the alternate action ?

I remember a discussion where it was concluded that load would sometimes 
not be useful for determining date validity.

but then if the string is not a valid datatype .. you could cause 
an untrapped error.

So, you have to wrap the whole operation around a try block anyway

got a quick example?

I am just transferring many files via ftp to a FTPZilla on Windows.
Aftert some time the ftp hangs.
If I use one steady connection, it hangs writing.

If I use one connection per file, it hangs with the message connecting.
Anyone seen a similar behaviour ?

Anyone got a csv parser that works with embedded quotes?