AltME groups: search

Hi Ladislav  welcome back 

I have no idea what curecode is ,  assume it is rambo5 or whatever

I don't need random numbers  myself at the moment  (I sometimes use 
hotbits )

I need to answer a homework question with something other than "don't 
know"  

I will go try to find out about curecode

Copied here: Answer: currently, there are two primary random generators:

1. old method, high speed, simple multiplicative:
    next = next * 1103515245L + 12345L;
    tmp = next & 0xffff0000;
    next = next * 1103515245L + 12345L;
    tmp |= (next >> 16);


2. much slower, SHA1() of a repeating pattern of the integer bytes 
(20 bytes total).

Hello, I have big conceptual problems with REBOL objects.  They differ 
a lot from common OOP. Inheritance is done by copying, no accessors, 
function redefinitions needs binding,  the object is composed of 
multiple blocks and I don't know how REBOL compiler interprets them.

I really ask myself why the REBOL object model is so different than 
standard OOP. I need some very good documentation but I have fount 
it nowhere. Does it exists ? Is it one of the best kept secrets ?

I have read that someone was able to buil a full class system using 
REBOL with multiple inheritance but this is a myth for me.

However, the question remains the same. Does a good article/documentation 
exists for rebol OOP ?

The main reason REBOL's object! model is not class-based is because 
it was initially developed after it became known that class-based 
OOP has a lot of downsides. That's wasn't known about class-based 
OOP at first.

Also I needed to have the ability to change a function in many objects 
like you do in other languages changing a single pointer to the destination 
fuction.

In prototype-based object languages, you handle code sharing with 
delegation. A "class" is a common object that many similar objects 
delegate to. Since delegation is explicit in REBOL, that means that 
object functions call other object functions or other functions explicitly. 
In the case you mention, you just assign a new function to the word 
in the shared object or global context.

Have any of you ever seen where the request-date requester does not 
display the correct month? For example, it will say May 2009 when 
it is actually displaying June 2009. Selecting a date will give you 
the june date. Using the /date refinement doesn't seem to help either.

james, yes, it's a known bug.

never noticed a date issue .. but then I use rebgui's date requester.

Giuseppe, in the context of REBOL as a messaging/data language, can 
you picture how it might work as a class-based model? And do you 
think a class-based model is more appropriate in distributed environments?

But believe me there is a deep gap between what the standard documentation 
teaches and what should be written there to fully understand not 
only objects but the full ideology behind REBOL.

Only asking to GURUS like you one can reach the level needed to have 
a upper gear in REBOL programming.

I have just added a STUB to R2 articles to write what I will discover 
about REBOL objects. The trip has just started.

Most of the inner schemes used in Rebol are hidden. Carl never talked 
a lot about them and never officialy

Giuseppe, I didn't mean to sound critical of you either. I just meant 
to pose it as a thought problem. Something fun to think about. e.g., 
in a world where you can send objects around, what does it mean if 
you can send a standalone object, versus one that needs a class to 
instantiate itself from? And what does that mean with regards to 
execution and untrusted code?

it's a problem since 2.7.6 ... when 'call was fixed ...

does somebody knows how to create a null-terminated string pointer 
for this api call?

winlib: load/library %user32.dll

SendMessage: make routine! [

    hWnd      [integer!]  "[in] Handle to the window whose window procedure 
    will receive the message."

    Msg       [integer!]  "[in] Specifies the message to be sent."

    wParam    [integer!]  "[in] Specifies additional message-specific 
    information."

    lParam    [integer!]  "[in] Specifies additional message-specific 
    information."

    return:   [integer!]  "The return value specifies the result of the 
    message processing; it depends on the message sent."
] winlib "SendMessageA"


the-char-result: make however the -> null-terminated string pointer 
???
creating a struct! doesn't work either.

char-len:  	SendMessage: hWnd WM_GETTEXTLENGTH 	0 		0

char-pointer:  	SendMessage: hWnd WM_GETTEXT		char-len  	the-char-result



WM_GETTEXTLENGTH is working fine but the WM_GETTEXT seems to need 
a pointer to a string.
any idea?

tom

TomBon... isn't "abc^(00)" a null terminated string? :-)

hopefully R3 will address a better pointer, struct (nested)  etc. 
handling. being able to use the tons of C/C++ stuff outside will 
enrich professional development.

you need to use a struct to get the pointer, or define the routine 
as taking a string argument.

TomBon - unless someone writes enhanced DLL wrapper as a plug-in, 
there will be no such thing as struct!, routine! in R3. You better 
look into plug-in interface, where there is much more freedom to 
do wrapping, but otoh it requires greater skill to handle it (C IDE 
set-up, compiling, etc.)

In Rebol 2.7.6 is it possible to set an escaped forward curly brace 
comparable to the ^} for escaping a closing curly brace?  In 2.7.7 
?  Or am I missing something.  I am trying for readability when my 
string tokens include both double-quotes and curly-braces and often 
span multiple lines.

^{ sounds like a good idea for 2.7.7.

As far as I know the current R3 console is a  temporary version.

I see the expected result in R2.7.6:
>> print read dns://www.rebol.com
205.134.252.23
>> print read dns://205.134.252.23
www.rebol.com

Maybe you have a firewall, proxy server, etc?

As you say, the ip address is correct.  but  I didn't use a firewall 
,nor  a proxy . I think  the problem  comes from my ISP

a windows call?

WuJian, No I was looking for a way for my app to know what it is 
running on...Thanks though..

Gregg, That looks far more intricate than I need but I will definitly 
keep it in mind.

I used a simple method...

first i used system/version to see what version of rebol is running 
so I can see if its Windows , Mac or Linux.

2nd- If its Windows I use 'Call/output "ver" win_ver' to get the 
windows version. I parse out what I need from the output. I just 
need to know if its vista as it has some file structure differences 
that screw up my "install".

Thanks for hte help...

We already have a list of priorities there.

Ok, just a little background info/goals:

1. I would like to release this week.
2. BrianH will set the priorities.

3. I can post any code needed to fix problems. But, if you make a 
change, be sure to test it really well. I do not have the time to 
test.
4. We can release again next month, and each month after that.

Right now it requires a license key for special features.

Sorry, I thought you released all the pro features a while ago ...

so, just release a license ??

simplest thing to do is just release a license ...

BrianH ..doing it right might mean a wait for a long time

Carl was also suggesting releasing a license to IOS ....

No it won't take long - it's just a matter of removing the license 
code and doing a rebuild.

os x but geomol ryoed on linux I think a swell

there might be a reason why there was such delay put into REBOL?

W: I've posted the C source to Call a few times, but no one has ever 
offered any fixes.

People need to nag me more if they contribute a fix, and it gets 
lost.

BrianH .. a public license means that everyone gets ssl, odbc, oracle, 
encryption today without waiting for a new build.

I don't know though if such a license would also be usable for the 
SDK ... which Carl may not want to do .

P: there is no reason for such a delay.  But, then, the code is not 
at all simple. If you've ever seen it, you would vomit. (PS: I did 
not write it.)

300 ms is a lot of time in response time when using call/wait or 
call/output in a Cheyenne rsp. Please fix it!

Will, that "echo" calls a cmd.exe internal command on Windows. Might 
that be part of the delay?

Give me a little time to go over them, I should have a list by this 
evening. I'm at work today.

I see a consistent 0.1 second delay in Snow Leopard.

B: Yep. Not a good thing for new users.

PS: need a better error msg for:
** User Error: Bad face in screen pane!

(happens when opening view via ssh - due to non X envr.)

So, what's the verdict?  Wait first for a new build or a public license 
code release?

It will be a build. Even if just a few changes.
Must go. BBL.

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

This is from a change I made in the timeout period of the io pipe 
handler.

However, I am unsure of the general impact it may have.  It causes 
the io pipes to be polled 10x faster than before... which may not 
be a good thing.

R2-Beta world is quite "old" (no messages for a long time). But, 
we could continue with it.

As far as I know ... a 2.7.7 release was planned there.

Yes R2-Beta because it already has many of the accounts already setup. 
 For a 1 week release and feedback that will be best approach.

I have an old View 1.3.2 here on Ubuntu where echo takes a bit over 
100 ms, so the bigger delay may be a recent regression

The 2.7 test release has been built. This is the base build for the 
next release. It contains SSL, ODBC, DES, etc., and no-license key 
is required.


In addition, I've added an install checkbox to the Prefs (User panel) 
and an Uninstall to the Help panel. These are just shortcuts to existing 
features.

The download is www.rebol.com/downloads/view277-test1.exe


Note that it's version # is 2.7.6, but it has a new system/build 
date. Don't mix it up with prior versions, as it's not at all tested.

Oh, and I almost forgot: This is a TEST. Use entirely at your own 
risk. Do not distribute. Do not use to operate nuclear reactors, 
missle defense systems, aircraft, heart-lung machines, etc. etc.

Seeing how he has released a free rebol command which currently lists 
for $349.

Graham, Your scheme is for pop only..have you developed a send mail 
scheme?

I never needed to do that ..always have a smtp server around and 
just use the gmail account as the reply to address

Graham, thanks for copying over those priorities from R2-Beta to 
here. About how those choices were made and phrased:


The R2-Beta world was used when we still thought of REBOL being updated 
more rarely, in larger increments. This is no longer the case, we 
are adopting the rapid release model, though more regulary than the 
R3 alphas. We need to shift our thinking accordingly.


Rapid release means that each individual R2 release doesn't have 
to include fixes for every outstanding bug. We can and will triage 
and prioritize, and your favorite bug may be moved to the next release. 
Which won't be a problem because that's coming next month, or the 
month after. Minor point releases will not be a major deal from now 
on, they will be monthly occurances.


The overall plan for the R2 2.7.x series is to fix what we can in 
R2 in a way that doesn't break things. This won't be a ground-up 
rewrite, as we are doing one of those already. No major model changes, 
just tweaks. There is a lot we can tweak though, including natives. 
We are trying to avoid disruptive changes that affect scripts at 
runtime, except in cases where things just didn't work before. Almost 
all code that works on 2.7.6 should continue to work - that is our 
goal. Don't expect broken code to stay broken though :)


The 2.7.7 release will not be ambitious, we just don't have the time. 
The priorities are business model changes and low-hanging fruit. 
The one piece of major breakage from the 2.7.x series that needs 
fixing in this release is the installer. If you have other priority 
fixes that can't wait til next month, and you are willing to do the 
work in this week, please speak up.

One personal note: In Monday and Tuesday of this week (local time) 
I have a day job. Please accept my apologies for not being as active 
here during that time. By Tuesday evening I will be able to more 
actively participate in the development of 2.7.7, but for now I can 
only coordinate.

It's been broken for so long, I no longer have the computer where 
I originally wrote it back in 2000 and posted it to the mailing list. 
It's still in my head though, so I'll collect it by Tuesday evening 
and start working. In brief:

- I don't know about installation on platforms other than Windows. 
Someone else will have to chime in here. Too ambitious for 2.7.7.

- Windows 2000+ support is still broken. Multi-user support is broken 
(same thing, really).

- Folder usage was mostly fixed in 2.6.3, but the registry is still 
misused. Registry migration will be needed.

- Non-admin installation should be possible, including user-specific 
file associations.

- Installation was broken altogether in the 2.7.x series - it doesn't 
work at all, not even to 2.6.3 levels.

- No-install usage of View needs better support. This means UI support 
too, if need be. VIew should be able to be a portable app.

Keep in mind that portable app usage of directories is completely 
different than installed usage, and needs to be.

can you post a release so we can test it if not?

As for installer, me, as a fan of copy&run principle, I would like 
simple option as Altme client has - on first screen, please allow 
"run from current location", and never ask again ...

In the long run I would prefer to make the installer configurable 
and encappable, but for now a View-specific one will do.

and when you start a rebol console .. you end up deep in user documents 
somewhere ...

So, if a program that is being installed needs Rebol ... where should 
it look?

Right. File placement is a matter of chosing the default folders 
of the installer, as it does now. You can change those choices.

As in almost all cases, Python is a bad example.

BrianH: so where can users (not admin) safely put his rebol scripts, 
so that rebol executalbe can write and read from such a directory? 
We can't do it in program files, but can we do in somewhere on C:\REBOL?

Or, will you use a standard installer script ?

Pekr, that is a runtime issue, not affected by the installer at all.

I can only SAY WOOOW on this release, I am still a strong R2 user 
and this is much more than appreciated!

Yup Graham. For me that should be a little sleep - I have to wake 
up again in 2 hours to go to a customer site. Pekr, stay on topic 
:)

Graham: thanks a lot for gmail related code, this was big hinge in 
some stuff I was planning

Here's my patches to http-prot.r .. http://rebol.wik.is/Protocols/Http

I have used it for a while and they do not break anything AFAIK ...

BrianH: how can you write your own client to R3 Chat? Can you actually 
use its command set? I mean - create a gui, and "send" command like 
"n", "lm", etc. to console in the background?

Pekr, you'd be surprised how much we can fix in mezzanine. Nonetheless, 
it is our job (well, mine) to minimize the impact that R2 development 
has on Carl's R3 work. We're keeping the native changes to a minimum, 
but the big part is testing and coordination.

No PARSE improvements this release unless Carl has a ready bugfix. 
Fixes to DECODE-URL are fair game though.

BrianH: Thanks... I would like to make it more a collaborative effort 
eventually. There are many things that need to be done, but I'm going 
to dive heavily into R3 in 2010.

LAUNCH affects the View desktop too. How is it broken? Is there a 
RAMBO bug report about this?

>> help run
USAGE:
    RUN file /as suffix

DESCRIPTION:
     Runs the system application associated with a file.
     RUN is a native value.

ARGUMENTS:

     file -- The file to open (file, URL) or command to run (string). 
     (Type: file url string)

REFINEMENTS:
     /as
         suffix -- (Type: string file)
>> run "screen.png"
** Script Error: Feature not available in this REBOL
** Near: run "screen.png"

I think I would have posted a bug report about 'launch ..

This isn't a backport of the model - that kind of thing can be handled 
by a rule compiler.

#4371 is a couple of lines of code and necessary to avoid crashes 
with DUMP-FACE on iterated faces. it should be simple to add.

Of note: I would not easily have found that memory leak if it wasn't 
for Instruments on OSX. It's a really nice tool.

Henrik, that #4371 fix sounds like a good candidate for 2.7.7.

Graham, I noticed it, when I was wondering why a simple two-button 
UI program with a bit of rugby networking ate up 500 MB RAM.

The main problem is that I will be hard-pressed to understand the 
implications of VID changes in the next 2 days. I don't currently 
understand the DUMP-FACE issue. If you can be sure of it and it can't 
wait a month, it can go in.

that's half a decade ago

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.