AltME groups: search

Again.. when talking about fonts.. I want bitmaped font support. 
For example I create font's for my Flash apps in Rebol using simple 
image where I draw pixel precise glyphs:
http://box.lebeda.ws/~hmm/fonts/fixedsys.png
And provide the needed informations in Rebol format:

http://box.lebeda.ws/~hmm/fonts/fixedsys.png.txt(using UCS2 to map 
the glyphs)
Then I use my vectorizer to get the Flash font format.

The last step could be skiped in Rebol. And just the bitmaps could 
be used. So as in my Flash apps I can be sure, that the font will 
looks like I really want it!

But first we must have the R3 core stable and opened host sources. 
I will wait:)

and that's mainly because of a lack of a suitable fast way to determine 
size of a bunch of text (we can use a face dummi and sizetet to calculate 
but that not fast

well i imagine that since the TDM (Text  Dialect Markup ) exists 
than AGG will follow and offer brand new things to handle conveniently 
the texte (and please please forget once for all about teh caret 
system please i beg you T___T)

what is in my opinion import in text handeling is to be able to get 
heigh and width taken be each letter or each set of letter (can be 
a word or a line ...

for example actually we are able to handle properly the text motion 
because we use fie font with a fixed size but this because what we 
want is to handle text in color and not mixe differnt kind of font 
styles and size like it would be the case for a MakeDoc format richtext 
rendering /editing widget

sure in our area-tc taht would be a plus to be able to handle ctrl+wheel 
action to grow shrink the text size (like you can do in any modern 
web browser for example) or to be able to set through a config panel 
the font size and type of your choice

and the "more 3365" bug is gone too.

That's a possibility. I'll try to compress your script tomorrow if 
I have time (it's late here) and see if it segfaults.

Pending means someone (me, usually) has already written a fix and 
submitted it to DevBase, but it's not built into R3 yet.

I don't understand a lot of these complaints where people say they 
can't contribute because REBOL "isn't open source". Large chunks 
of R3 were written by me, and every line I wrote was open source, 
freely available in DevBase.

A lot of REBOL is written in REBOL, and all of that is open source 
(in theory). The source is all in DevBase.

Graham, VID+ was being worked on in order to get the core in good 
shape, by uncovering bugs and helping set priorities for fixing them. 
Now we are fixing the most important core bugs, including the one 
that has been blocking infrastructure development the most: the lack 
of a decent, working module system.

Now the thing blocking us is the lack of a multitasking model, so 
we are (mostly Carl is) implementing what we need to get multitasking 
working: memory protection and a new system object. It looks like 
we will have a shared memory model after all, rather than a shared-nothing 
approach. It's still up in the air though.

wow, now you are focusing on multitasking.. that is a big core thing 
... if there will be shared memory model we can probably build various 
other abstractions on top of it (I did observe some backslash vs 
pure message passing / actors lately also -- especially for concurrency 
on the same computer / cpu ) ..  this is interesting thinking IMHO 
http://clojure.org/state"Message Passing and Actors" under "I chose 
not to use the Erlang-style actor model for same-process state management 
in Clojure for several reasons:"

well he uses quite complex thing in form of persistent (functional 
-imutable (versioned)) data structures... that is probably something 
too complex to focus on now.. but if we have simopler / more primitive 
means of concurency we can probably build stuff on top of it .. and 
even try with some fancy data structures (factor folks were playing 
with them so they are doable)

persistent here doesn't mean it's in a db or a file but it means 
that data structures in clojure are immutable and theoretically when 
you change one you always get a new copy so threads can't break stuff 
to other threads in the middle of process, but the catcth is that 
that copy is not really a copy (which would be simple and *expensive*) 
but same structure reused with some different paths so that it is 
different ( I hope I made any sense ) .. he explained it in some 
video very nicely

seeing that I have Windows 7 running under VmPlayer, I decided to 
try the r3 beta and can report that I does work :) The only problem 
was with the demo/Reactor. When I tried on open an examples file,Windows 
complained about the file type. The same thing does not happen on 
XP Pro ?

Interesting...


I'm using blocks to manage a lot of name/value pairings which I will 
sort and copy/part the top x items.  I was hoping to be able to utilize 
the speed of map! for doing this.  Maybe I should use map! while 
creating/modifying and then when it comes time to pull top x items 
I could convert it to a block...

map! is for lookup and deduplication, yes.

Ok, good enough.  I think that will work.  I'll modify some of my 
scripts to use that method and then do some benchmarks...

While I have your attention and I'm thinking about sorting I just 
thought I'd mention that I'm using the following work-around for 
the lack of /compare in sort:

; R3 /compare bug work around
sort-compare: func [
	blk
][
	; disorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	; sort em
	sort/skip/reverse blk 2
	; reorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	blk
]

The map! type is used extensively in the GUI, and some mezzanines. 
The MAP function's name wasn't my idea - some Haskell fan thought 
we needed a map function (true) and that it should be called the 
same thing (not REBOL-like). This came before the name of the map! 
type was chosen, and prevents us from making a proper functional 
map function of that name. At least we already had a fold-like function 
with a REBOL name: REMOVE-EACH.

Ammon, that is a known (already submitted) bug, and not the only 
SORT bug. Work in progress :)

hmm, then you could say the same for apply too, and probably foreach 
should be renamed to for-each, etc :-)

I know it's reported and in CureCode.  I'm just saying that I'm working 
around it now in the hopes that the priority might be bumped up a 
bit. =D

BrianH: what is 'resolve good for? Couldn't it be achieved with some 
mixture of difference, intersect, and such? :-)

Not as quickly, and those work on blocks, not objects.

Darn, /only doesn't work there. I was trying to come up with it on 
the fly and I failed, miserably :(

Oh, I love it. The old system object was chaotic. This one will be 
organized. We need this for memory protection and multitasking.

R2 works now, but it has a lot of design flaws and bugs we are fixing. 
That's why R3 is different than R2.

Codecs are like port schemes, but for encoding and decoding. Different 
thing.

So why is View separate, and not in Modules section?

... and  - what is Contexts?

We need to have volatile settings separated from unchanging settings, 
becuase the unchanging stuff can be shared between tasks and the 
volatile stuff can't. And the hidden stuff can be tricky to access 
if you don't know what you're doing, so that is separate too. The 
new organization strategy makes sense. The only thing I miss is system/user/home, 
so we'll need a new place for that too - maybe system/options/user-home.

I am thinking of a preferences system too. But that is not really 
a problem - user.r can be good place to place various settings. What 
we haven't solved or even thought about is - localisation. Messages 
and other stuff are hardwired into the system. I don't want to translate 
REBOL itself, but e.g. R2 does not allow easily callendar data being 
translated. Other thing is currency, flating number separator (for 
display purposes, etc.)

The main thing you need system/user/home *for* is to know where to 
look for %user.r - it is not safe to look for it in the current directory, 
and not multi-user-friendly to load it from the same directory as 
%rebol.r. R2 is horribly broken in that.

And really BAD. It's a security hole.

BrianH: yes, but I work in Total Commander, and I work with directories. 
I need to learn how to do some shortcuts, because going down that 
directories to locate some file is a pain :-)

BrianH: what is outcome of read/text discussion? I did not like the 
proposition, because while text operations might be common, text 
is just format as any other is, so should be decoded using codecs 
(which can be chained). OTOH just yesterday I used read/lines. I 
use it very often for external formats, to parse in foreach loop. 
So - what will be the equivalent in R3? 1) 'read gives me a binary 
2) I convert to string 3) then I parse .... or 1) I use load 2) which 
does read it for me and converts to text using some codec ... but 
still - where is the place to turn it into line delimited mode? Will 
we have to use parse rules then, or where would you put something 
like /lines /with R2 equivalents?

READ/text seems like a lock, sorry. You may think that text is just 
another data format, but it is the *most common* data format, and 
tends to be processed in large quantities. You say that codecs can 
be chained, but they currently can't - you can apply them one at 
a time, with all of the intermediate forms in memory at some point. 
If we do text the way you ask, then every load of text for processing 
will have the additional overhead of a full duplicate of the ram 
and two series moves, plus a few lines of code. READ/text is a shortcut 
that will save a *lot* of overhead during what may be REBOL's most 
common operation.

I don't agree that text preloading would cause a duplicate. Are you 
trying to suggest, that codecs are such pigs, that they do first 
read the whole file, and then decode? Then the system is flawed, 
because what you do with the 9GB video then?

BrianH - the thing is, that I don't like exceptions ... :-) ... but 
I can understand, if some exception covers some 80% of usage cases. 
REBOL is not about purity, but about practical aproach. But I still 
don't believe in the explanation you provided :-) and btw - Carl 
said, that codecs should be chainable, so hopefully it comes?

Steeve - as a side - note - I posted to Carl link to your editor, 
and he might blog on it. He just said that now he understands why 
you wanted virtual blocks :-)

Pekr give CArl the link to the wiki track he will get some of hours 
past days coding experience what we tried and why we concluded in 
doing the things the way we do them

Pekr, right now codecs only decode binary! and encode to binary! 
- I mean values of the datatype binary! that are already in memory. 
So yes, codecs currently *do* require that you read the whole file 
first. Streaming isn't there yet.

I want codecs to be able to work on open ports. TRANSCODE, SCRIPT? 
and PARSE too :)

Quick survey: Do any of you use %rebol.r and/or %user.r, and if so, 
for what?

We are discussing the possibility of removing those files from R3, 
and replacing %user.r with a declarative preferences file, for security.

Yes, presumably - definitely *not* code. Gregg has been requesting 
a preferences infrastructure for a while, and it's a good idea.

I use user.r to add functions which I use in Console. If you remove 
it, I can create a boot script myself and call rebol with it. I almost 
never run Rebol script just clicking on them.

Oldes, I frequently call REBOL scripts by just clicking on them, 
but those scripts load utility functions and halt to the console 
:)

Also I patch default 'attempt function and http scheme (to be able 
use cookies transparently)

I'm not sure the code is so good to be accepted and also not all 
people want to use cookies.

I use user.r to get some UNIX like commands and for get an include 
command. Will probably not be necessary in the future (now we got 
unix commands and with modules).

Yeah, I have just been working on a whole-package browser spoofing 
client, not just the user agent. I should clean it up and port to 
R3.

BrianH, yes, it would be a good test of modules and ports. if it 
could be started from the start screen, that would make it even more 
attractive.

I mostly work with the files in 26 (Mezzanines) and 837 (R2-Forward).

I have thought of using user.r or Rebol.r as a way to run a script 
to log my execution of scripts, although I have not done so.  I tend 
to think of those two items as a "hook" where I can execute my own 
generic code for whatever purpose needed.  I have often thought of 
having either Rebol.r or User.r enforce protect on system words and 
then make sure Rebol.r or User.r is read only, but there may be other 
ways to do this better.  I am still new to rebol.

BrianH:  I use user.r for a few little things, but mainly I get it 
to call my anton-user.r script. I forget when but there were some 
instances  (when I was on Windows) where rebol would overwrite user.r 
(testing a fresh rebol beta?). That's why I decided to get all my 
code out of it and just DO my anton-user.r script from it. On linux 
I also set system/options/home where I want (not the user directory).

I don't change environments much. All new rebol executables are placed 
into the same directory and beaten with a stick until they work using 
the same user.r and my anton-user.r script.

BrianH;  All my nodes have a %user.r.  I define all my comand line 
shortcuts there.
Things like

ls: :list-dir
dir: :list-dir
cd: :change-dir
pwd: :what-dir

~: :view-root
.: %.
..: %..

scripts: :view-root/library/scripts


And those usually work best with GNU/Linux when I just know it'll 
look in ~/.rebol/view

Brian, ls, cd and pwd are predefined in R3. We're considering putting 
in ~ handling in many functions.

Pekr, the reasoning behind blocking patches is the same reason there 
is no browser plugin - R2 is insecure, and R3 won't be. Every patch 
that you can make in your %user.r is what malware running on your 
system can make with your user permissions.


The goal is to have tons of REBOL hosts around. Every application 
with a plugin interface could have a R3 host as a plugin. R3 is going 
to be able to generate programs now, not just scripts. It'll be a 
real development tool.


The problem with all this is that being able to patch the runtime 
using %rebol.r or %user.r, so can anyone else, and you won't know 
about it. Can you say exploit? We already had a false positive for 
R3 this year, an old alpha mistakenly marked as malware. We don't 
want the next time to be for real. The only way to avoid that is 
to make R3 secure.


The way to make something secure is to make the behavior of your 
code predictable. That means making your requirements explicit.

It will be easy to specify your requirements in R3 - we have modules. 
Put your patches in a module and either add that module to the Needs 
header of your script, or include it on the command line, or build 
it into your host program. Like the SDK but better.

Ah yes, I remember something about that. I had same problem years 
ago. The url is correctly recognized as a url, but trying to use 
it, and it fails.

Pekr.. it's not too practical and safe to use urls with passwords. 
And if you need to connect to ftp with such a user's name, using 
scheme directly should work

Oldes - you see? that is exactly that nonsense excuse I am not willing 
to accept. This whole discussion was started only in regards to planned 
cancellation of user.r and rebol.r, so I was curious where I put 
my own patches ...

so - for me - it is bug in the parser, as such format is clearly 
allowed and is used daily on many sites, for others, it might not 
follow some RFC, and we have some workaround (RFC). But with REBOL, 
which does not use pure aproach here or there anyway, I don't see 
the reason why such stuff should not be possible. And xy users asking 
the same question over and over again thru all that years on ML prove 
me being right ...

no, I think no other consequences. IIRC, I extended that parser by 
# char too, but don't remember when it was. Remember - user.r and 
rebol.r are not going to be provided anymore, because of security 
reasons, so you have to either:

1) add your script into 'needs header for each of your script

2) start your script with special command line option, probably --include 
(but that does not allow simple double click functionality with associated 
executable)
3) build your own R3 host executable

4) prey, that your patch is usefull for others, and try to submit 
it to R3 CVS to be accepted

Geomol.. because there are people which wants to follow RFC! The 
above Pekr's "patch" is against RFC. One thing is, that you can use 
chars like @ in user name FTP's scheme. and another is that you cannot 
use it in URL. But that's not the topic here. The topic is,that Pekr 
want to modify his system against standarts - then he can use SDK 
and build his own URL handler.

From RFC 1738:
Within the user and password field, any 
:",
   "@", or "/" must be encoded."


Pekr, can you get it to work without your patch, if you specify the 
at sign in the username as %40, like
ftp://john%40niclasen.name:[password-:-someserver-:-net]

Petr, chunked transfer mode is useful when an HTTP response is returned 
and the content length is unknown (for example, it is being dynamically 
generated from a source which is streaming it out). It can also exist 
when an HTTP response is being handled by intermediate proxies that 
could, for example, compress the response for a part of the path 
to the client. I've seen this on a cell phone where a POST was made 
with a fixed content length, but the web server received the request 
as chunked, with no length.

It would be nice, if the parser auto encoded :, @ and / when needed.

I guess, auto encoding is user-friendly, if it can be done right 
in all cases. With auto encoding, you don't have to remember all 
the strange encoding rules for different datatypes (especially url 
and email).


No auto encoding is technical-programmer-friendly. It's for the programmer, 
who knows all the strange rules and want complete control.


It goes beyond url and email. How should a space be represented in 
an issue! datatype? Like:

>> to-issue "a b"
== == #a?b

Today you just see a question sign, but it's a space in there.

Geomol, yes. I would like to avoid auto encoding. It's exactly the 
case where I had the problems. If I write file as %"a b" and it's 
valid file, I prefere to have it samewhen I for example print it

I understand the concern against auto encoding. But without it, and 
with all the datatypes, we have in REBOL, good documentation about 
what encoding, we have to use for every datatype, is required.

Gabriele, RFC compliance of url encoding is important and will be 
fixed in upcoming R3 releases, even if I have to fix it myself. R2 
as well if I end up being the R2 release manager (it's possible).

Yes, but to see it running (I only saw your images prior to this) 
was exciting.  Thanks and take care you all.

Geomol, sometimes I don't know what language I'm speaking in. We 
were talking about URLs, weren't we? files and emails are rebol values 
with rebol rules. url! also has rebol rules which is the main problem 
- REBOL considers %40 and @ to be the same, while they are not (if 
they were, there would be no reason for escaping).

Are you having a bad week?


I'm in doubt about auto encoding, whether it's a good idea or not. 
And I talk in general, not just one datatype. In R3, you can use 
% in an email:

>> a%[b-:-c]
== [a%25b-:-c]


I first thought, it was an error. After some talk here, I realized, 
it's auto encoding of the % character. In R2, you have to write the 
encoding yourself:

>> [a%25b-:-c]
== a%[b-:-c]


So it's the other way around between R2 and R3. Clearly Carl try 
to make REBOL smart. Make it figure out, what the programmer mean. 
In general with computers, I tend to dislike the systems, that try 
to be smart, if they don't get it 100% correct in every situation 
(Windows), and I like the systems, that does not try to be smart 
but put the user in charge (Amiga).


So at this point, I think, auto encoding should be avoided. And avoid 
it in all datatypes, not just url. I may change my mind, if auto 
encoding can be done 100% correct in all datatypes. For url, it would 
mean e.g. this:

>> to url! "ftp://[me-:-inter-:-net]:[pass-:-server-:-net]"
== ftp://me%40inter.net:[pass-:-server-:-net]


So my question is, can auto encoding be done 100% correct for all 
datatypes? If not, avoid it. If auto encoding should be there in 
some cases but not all, I would like to hear the arguments for that.

Geomol, we're talking about two completely different things, and 
if you don't see that, I don't really know how to explain it.

I'm talking about "escaping", while you use the term "encoding" ambiguously 
to mean both encoding and escaping. THEY ARE TWO DIFFERENT THINGS.

Gabriele, I don't think, I got it wrong. From RFC 1738
http://rfc.sunsite.dk/rfc/rfc1738.html


The word "escape" is only used in the BNF in section 5. Escape is 
defined like:

escape         = "%" hex hex


That must be what you mean, when you gave the example of an url with 
the problem:
ftp://user%40email.com:[pass-:-ftp-:-domain-:-com]

When REBOL read that url, it convert %40 to the @ sign. Throughout 
RFC 1738, the word "encode" is used, when a character needs to be 
escaped. Like in this - taken from the RFC:


The user name (and password), if present, are followed by a
   commercial 
at-sign 
@". Within the user and password field, any ":",
   "@", or "/" must be encoded."


So "encoded" mean escaping the characters, right? I think, that's 
how I used the word in my comments here. If you think, I got it wrong, 
could you explain it to me then? I would like to get this right.

And please try not to shout. There's no need to shout at me.

Carl states he was working on rebin last week (which is prerequisite 
to host to core code isolation and finally open-sourcing R3 host 
code), but found some problems, especially for Draw, which needs 
to be dynamic ...

I would also like to ask about one Carl's Chat message, describing 
DELECT. Do I understand it correctly, that first Carl thought that 
DELECT might be used for some interfacing, but that DELECT is kind 
of functional/procedural aproach which does not fit the concept, 
and hence instead Carl is considering action! kind of aproach?

DELECT was supposed to be a way for Draw-style dialects to be done 
without exponential growth in the size and runtime of the parse rules 
to handle them. However, it turned out to be not powerfuul enough, 
so it is due for a revamp or replacement.


The days of "just make a dialect" are over - we have improved the 
performance of REBOL to the point where the overhead of processing 
dialects is now noticable enough (in comparison) that you need to 
be really careful about dialect design and implementation. Or about 
the choice to use a dialect at all.

Now about libjit, I considered it years ago, but it was GPL 2, and 
GPL 2 code is license incompatible with REBOL. As of the new version 
released in December of 2008 libjit is LGPL 2.1, and we can use that 
with REBOL. It supports more CPU platforms than TCC and it is about 
the same size. Here's some links:
- http://www.gnu.org/software/dotgnu/
- http://savannah.inetbridge.net/dotgnu-pnet/libjit-releases/

Dialecting isn't any slower, it's just that everything else has gotten 
quicker in R3, and dialect processing just seems slower in comparison. 
Dialecting just has to catch up with the rest.

BrainH: well, for me dialects should not be introduced just for the 
sake of using dialects, but for kind of API environments, where they 
make sense. And - you "compile" them to REBOL code in the end, I 
think that the cost is not very high ...

it is in your *source array* (re: shouting, i just want to give emphasis 
but we don't have rich text, and the * thing does not work very well 
for long text) that you must distinguish between @ (the field separator) 
and % 4 0 (an escaped @, part of the url field text). There is no 
encoding process that can *automatically* go from your array of integers 
to the correct url string.

Maybe we got unicode encoding end escape encoding confused.


As I see it, given correct rules, auto converting of user input to 
correct url can be achieved. I made this function to illustrate, 
what I mean (it's not optimized, but should be easy to read):

encode-url: func [input /local url components host] [
	components: parse input "@"
	host: back tail components

	url: clear ""
	append url components/1
	components: next components

	forall components [
		either components = host [
			append url "@"
			append url components/1
		][
			append url "%40"
			append url components/1
		]
	]
	url
]


I can use it both with and without specifying %40 for the first @ 
in the url:

>> encode-url "ftp://[name-:-home-:-net]:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"
>> encode-url "ftp://name%40home.net:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"


It will give correct result in both cases (I use strings, but of 
course it should be url! datatype in REBOL). Now comes unicode. Given 
precise rules, how that should happen, I see no problem with encoding 
this in e.g. UTF-8.


So I think, it's possible to do this correctly. But maybe it's better 
to keep it simple and not do such auto convertions. In any case, 
the behaviour needs to be well documented, so users can figure out, 
how to create a valid url. I had same problem as Pekr years ago, 
and I missed documentation of that.

unicode encoding *and* escape encoding

Yeah, maybe give functions like mine above, that users can call and 
get their input encoded, instead of having to know all the escaping 
rules themselves.


If that solution is choosed, then this input should give an error, 
as it is an invalid url:

ftp://[user-:-net-:-net]:[pass-:-server-:-net]

Today R3 just accepts it.

Great!, Ladislav Mecir just registered to R3 chat! Hopefully he will 
be back and is OK!

Someone hit him up and tell him to jump in here.

Geomol, so that will give you the correct result for *two* cases. 
Cool. What about the other billion cases? :-) I'd like to understand 
if you have ever worked with this stuff in real life, and to what 
extent, because in my experience what you did above makes no sense 
at all...

On the new R3 GUI document: I think the new guides and layers concept 
will work much better, but of course it depends on the implementation. 
I've asked a range of questions in Chat to get some more information.

Doesn't guides concept reminds 'AT concept in R2, and hence absolute 
positioning, which we were against?

re the %rebol.r and %user.r files:
* I do not use %rebol.r for anything

* I use %user.r to set up my personal preferences on every machine 
so, that it looks like I expect it to: defining my personal "absolutely 
necessary" functions

functor: func [

   "Defines a user function with all set-words collected into a persistent 
   object (self)."

    spec [block!] "Help string (opt) followed by arg words (and opt type 
    and string)"
    init [block!] "Initialization block of the persistent object"
    body [block!] "The body block of the function"
][

    make function! reduce [copy/deep spec bind/set/copy body make object! 
    init]
]


We decided to not use the term "static locals" since it would be 
confusing to people not familiar with C languages.