AltME groups: search

(Until we can catch them properly with TRY)

I'm not sure yet what the optimal way would be for runtime refinements 
evaluation, I've used a bitfield-based caching method in R-sharp 
to pay the full cost on first evaluation only. I'll try to implement 
a similar method for Red interpreter later. For the Red compiler, 
the cost is paid once only during compilation, there is no specific 
runtime overhead.

I wanted to try the console on MacOS, but got missing /usr/lib/libhistory.dylib 
.. is it supposed to be working?

Thanks. I would expect LibReadLine to be loaded before LibHistory, 
so the fact it errored on the latter may mean that it has loaded 
ReadLine successfully. Others often try to have a compatible interface

If so, you can try to comment out the #import of History-library, 
and in INPUT, "add-history line"

Doc, it was for Try Rebol site, not my own one attempts to test ...

I'll try, but no promises. ;-)

OK.  Thanks!  I'll give that a try.

Try VIEW ["Hello" button "OK" [quit]]

Just clone a fresh copy in a temp folder and try recompiling the 
console.

Oldes: you're right, I'm becoming a bit too careless, I'll try to 
get something done at least tomorrow, then I'll go swim in the sea. 
;-)

Try this in Try REBOL:

Haven't checked to see if it's a known issue, but if I append/dup 
with a large number of elements it crashes. I'll try to track down 
the exact number. 75K does it, 65K does not (in a quick int append 
test).

Ok, thanks, will try to reproduce the false alarm and will contact 
AVira for reporting it.

Good to know. Thanks. I'm trying to stay just a few steps behind 
you in what I try. :-)

Pushed. If you give it a try, please let me know if it works for 
you as well.

Yeah it will be great. People can try Red & R/S easily then.

Have you previously done a while loop in Red/System like that? Try 
it a little simpler while [0 < len][mem: mem + 1 len: len - 1] to 
be sure it is not the combined statement that is confusing the compiler. 
(Just trying to help here until the real experts jump in)

so try

while [all [mem/1 <> string/1 len: len - 1 0 < len]][mem: mem + 1]

Here's what happens when I try to compile Latin-1 source code:

I use Textpad on Win7 for coding. As Textpad does not support Unicode, 
I also use Notepad++ for Red UTF-8 scripts. On Windows, I use PE 
Explorer for reviewing the disassembled code and IDA Pro for debugging 
it (hopefully, this happens rarely). I also use IDA Pro on Linux/IA-32 
and gdb everywhere else. On Mac, I try to use osxdebug, when it's 
not crashing.


I dream about the day when I'll be able to replace all those tools 
with a cross-platform Red[/System] IDE.

Don't tell me that. I want to imagine that it's *reeeallly* hard 
and bad things will happen if I even try to understand it. :-)

You can test Red I/O on Try REBOL. It runs the red-core interpreter

Anyway, if you try GTK-IDE, you'll get output in the window

I might try downloading 32 bit version then ...

Will try on a 64-bit too...

Ah, will try to upgrade mine to 0_26 at least.

Ok, try adding -d32 option when launching the app.

I might miss some basic OS understanding. Guys, how do you work with 
all the path? I have JAVA installed, REBOL installed, yet what I 
am strugling with, is path. When I follow docs, it always seems to 
be easy. Docs state:


do/args %rsc.r "-dlib %bridges/java/JNIdemo.reds -o %bridges/java/JNIdemo"


well, for normal user, in order to try that, user needs to understand, 
he has to start Rebol for that. So there are basically two options:


- running REBOL from icon. Then you have to change-dir to where Red 
is - in my case, something like C:\!Rebol\Red

- I thought, I might use just "pressing ENTER" upon Red.r, which 
launches console for me. But above still will not work, unless I 
change-dir into red-system subdir. It should be imo either stated 
in the docs, or some shortcuts provided, e.g. red-system.r, allowing 
me to launch console directly in that subdir, and then above command 
would run just OK.


I am not stating anything is wronk, it is upon user to improve the 
workflow, but surely it is an obstacle for occassional user.

Now back to docs:

2. Compile and run the JNIdemo.java app from console:

        $ javac JNIdemo.java
        $ java JNIdemo


Well, when in console, my console does not recognise javac, nor java 
executables. Apparently a path problem, but I have JAVA installed 
via installer. So I have to go inside JAVA dir, which means:

cd c:\Program Files (x86)\Java\jdk1.7.0_21\bin\
javac c:\!rebol\!Red\\red-system\bridges\java\

Any tips? :-)

Can you try a `ldd` on any Red[/System] binary?

I'll try to remember when I get back home in front of one of my Raspberries.

Marco, can you try it with a simple Red/System program that just 
contains a call to Sleep(1000) (needs to be imported from C lib)? 
So we can see if it's related to Red/System or to your program.

So if I would try install the gtk+ using brew, do I write:
brew install gtk+
?

I try. :)

nah, I try. :)

The easiest way to try Red on Mac is to get the red-core interpreter 
from here:

It would surely be interesting to try to port the World mezzanines 
to Red

I/O is not in Red, only in my extensions. DO is the internal interpreter, 
so it doesn't know about my I/O. It's a good point, I should try 
to override DO

WHAT is quite essential on Try REBOL for new users

Geomol - try to understand your example. Imagine html file for e.g. 
Your [to a | to b ...] is wrong ... imagine 'a is at the end of the 
file. Simply "to a" will find it, before "to b" is even given chance 
to be applied. What we want is - find what is first - 'a or 'b ....

I try to think about, how I solved such situations in R2, or maybe 
I never had to. Hmm

Parse: I simply wanted to try porting Topaz's PARSE. Not sure if 
that would or could become the built in one. I hope to still be able 
to do it eventually... we'll see.

I could try to do something like that, but it will be a playlist 
under my account, not very findable/ related to REBOL/Red

OK Doc I'll try it later as I must go to work now and I'll send it 
back results to you later. Thanks

Gerard, found the native crash dump info in your log file, thanks! 
We'll give it another try with the new bridge version once ready 
(this week).

ehm both very fast.. timer needed. (cooking now, so will try that 
later.)

OK, so will ask in a different way (wrt Android) - will there be 
any official release, an example published, or even a blog article? 
If not, I will post as we go. If so, I might wait, so that we can 
refer ppl to download it and try to do their own small steps ...

I also plan to add a quick support for compiling kernel drivers for 
Windows. It shouldn't take long and some users need it, so I will 
give it a quick try.

this would be an nice way for users to try red and progressively 
replace their binary code base, one source file at a time... instead 
of a whole project at once.

Yes I know, I built one in already, except when you have shifted 
the ran_arr_buf, this one shifts along, but I want to return then. 
So I saved it in a sav_arr_buf to take care of this. All in all because 
I try to stay as close as possible to the original I have some extra 
bookkeeping to take care of. Later today I will clean up the code 
further and hope the smoke clears up ;)

You should try passing the function! pointer as integer! then type-cast 
it inside the function. IIRC, function! cannot be  yet used in a 
Red/System func spec block.

I write a simple test  try to understand it, it's can be compiled, 
but the output is not expected

Pekr, I will try again

Yes, because the compiler is not yet able to process `cmp-func [cmp-func!]` 
correctly. Try to declare an integer! there and then type cast it 
to a cmp-func! inside the body.

New try for the Red port on Android demo:
http://static.red-lang.org/hello2.apk


This time it should work fine on all devices, please let me know 
if you find any issues. Just be sure to uninstall previous version 
before installing this one (just to be sure you won't report false 
positives).

ok, good to know, moving home from work, will try in the evening 
....

For instance, I try to compile and run the following simple script:

Red []

img1: load %img1.jpg
print img1

And even try to initialize img3 by 
img3: read-file-binary "img2.bin" :size2

that way img3 can be subscripted like img1 and img2, not sure now 
about your as-binary from integer what you have now.

I am not familiar with Kaj's Libraries but I searched ANSi.reds and 
the Red/System runtime to try to find where as-binary is defined. 
I guess it must be in one of Kaj's other libraries.


I noticed the ANSI.reds includes %common/FPU-configuration.reds but 
couldn't find that in Kaj's Repo. (It doesn't sound as though it 
would include a definition of as-binary though).

So you're pointing img3 to a semi-random memory area that happens 
to have an address equal to the size of the first image. That will 
crash the first time you try to access the image

Interesting, the lines for downloading that are commented out. I 
will try it again. I do have the JDK installed as I was doing some 
driod app stuff a while back.

It may be an issue with the dereferencing.

Could you try by assigning img1/r etc to temporary variables.

@james_nak, first delete any jarsigner exe you might have downloaded 
or copied outside of the java folders. Then try to run jarsigner 
from the Red folder, if it says it can't be found, then you have 
to add to your PATH environment variable, the path to the java/bin/ 
folder of your installed JDK.

But I did it through Synaptic, I might try to do it manually...

Try to delete the whole builds/ folder and try again.

Not so easy. I'll have to resort to building a really simple example 
and try making that work.

Try adding an explicit null marker after each append

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).


Red currently emits only the standard ARM opcodes, so 32-bit per 
instruction. We'll add support in the future for Thumb mode (more 
compact instruction set). In the meantime, you can try to activate 
the literal pools by adding the following option to the Linux-ARM 
config block (in %config.r):

literal-pool?:	 yes


That should both reduce final binary size and give you a little speed 
improvement. But be sure to test is well as this mode has not been 
much used yet. Also, it might fail to compile if you use very big 
functions, or a lot of code in global context.

Hmm, I guess we should try then implementing a suitable callback 
to answer properly to SCM commands...

However, the driver just has a skeleton success return entry point, 
it doesn't try to take any devices or anything yet

gets() requires you to allocate a buffer of adequate size. Empty 
c-string! literals ("") will statically allocate an empty string, 
unsuitable for use with gets(), resulting in buffer overflows ('boo 
is allocated just after 'foo). Try rather: 

foo:  allocate 100
boo: allocate 100


This will dynamically allocate 100 bytes for each c-string!. You 
need to ensure that gets() won't overflow those buffers (which in 
practice is impossible, so one should just avoid using gets() in 
production code).

One interesting use of isolated modules is to use IMPORT/no-share 
to force a module to load isolated even if it wasn't written for 
that. This is a way to use modules that are too messily written, 
that make too many unnecessary changes, and try to limit the mess 
a bit.

Agreed, and speaking of which I also noticed RETURN/redo, which even 
has a visible option and I didn't notice it before. It's a general-purpose 
function trampoline, and as hard as I try I haven't run out of new 
ideas for how to use it.

One of the problems of SO (generally, not in this case I hope) is 
that the asker chooses which answer is the accepted one, not someone 
who knows enough about the situation to know which answer is better. 
So I tend to try to work around this social bug by answering earlier 
to discourage less-informed people from trying to answer badly. In 
this case, I have to answer because I'm the one who designed and 
wrote the function, at Carl's request.

Thaks, I will try it

Thanks, I will try it

didn't try ... !

Regarding the zlib code change/update. I think that is feasible. 
We could try to use the latest version of ZLIB library (hope the 
licensing is ok, haven't checked that) or look at the MINIZ compression 
library (check it on: http://code.google.com/p/miniz/looks interesting 
as it could be more lightweight)

cool, so looks like we could try to replace the old code in the future 
with these and see if it makes R3 better.

The LiveCode KickStarter campaign to first re-structure the code, 
make it easy to accpept contributions, build a new IDE and some modernisation 
has raised over 500,000 GBP (more than 750,000 USD).


Same Carl didn't try something along those lines before releasing 
REBOL 3.

You can throw more words at the problem to try to make things less 
ambiguous, but that doesn't always work and tends to make your speech 
patterns a little off-putting or overbearing. Some people don't take 
well to overly-precise English. You have to balance things.

@GrahamC:  Yes. I am going to try to find the source of the problem. 
This used to be my job at RT. ;-)

It could be specific to R3 on Arm.  I'll try it on Windows before 
tracing any further.

Good, thanks for looking that up. I can try building on Haiku later 
on.

Ladislav, try to keep on topic. We're not talking about CFOR, we're 
talking about FOR :)

I've used some languages that try to prevent ranges which are opposite 
to step (with an error) but I found that very annoying when playing 
with code which uses variables for start & end values.

If this was a language designed to promote "proper" programming, 
I could see having constraints on every function to keep them from 
being used in new ways, and to promote the proper usage of the function. 
 However, in real life, flexibility is key.


Let me know if this makes any sense:  If I want to rip the fender 
off my car and fashion it into a medieval helmet, physics allows 
me to do so (if I had the requisite skill).  However, in programming 
languages, this type of thing would rarely be possible.


So what I'm saying is this: Try as much as possible to refrain from 
placing software developers in a box when it comes to how they might 
choose to use a function or a feature.

Try as much as possible to refrain from placing software developers 
in a box when it comes to how they might choose to use a function 
or a feature.
 - yes, makes sense to me, Bo. I alway try to achieve that

Flexible and powerful isn't enough. I know this is difficult Ladislav, 
but try: Imagine that you're dumb. What would dumb you want?

OK, nevermind. I will try to be understandable for you:


if you want to do so, you *can* eliminate the only combination of 
START, END, BUMP values that causes infinite loop by default while 
still remaining consistent at the cost of disallowing something that 
may be perceived as "legitimate" by some users, and as an "unsolicited 
for" limitation.

aha, I swapped the condition, try with either negative? bump, please

Nice! I must try it sooner then later ;)

@MarcS:  I'll try sha256 with Amazon AWS - very helpful, thank you!

To me, it's a matter of whether SPLIT-PATH should be consistent in 
how it handles the path, as a string to process, or whether it should 
try to be "helpful". The problem with being helpful is that it may 
make other things harder.

For those interested in the "alpha-channel change":

Here is the branch with first round of related code changes to the 
image! and image codecs: https://github.com/cyphre/r3/commit/472c106a0f177ead82a6f29be1ae98b4cd33b9ad


Note: This code doesn't contain any graphics related changes...just 
the image! datatype + image codecs so you can MAKE images and load 
BMP, GIF, PNG and JPG files. But it should be enough to test the 
change.

(I have this code already intergated with changed AGG graphics and 
it works well but I haven't published it as this part is not compatible 
with the 'official' git source at the moment.)

Note2: the code was not tested on big-endian systems so it is possible 
there can be some quirks. Use at your own risk and let me know about 
any problems.


The RGBA tuples on IMAGE! now work so if the fourth(alpha) value 
is not defined it is assumed the RGB tuple is opaque (ie. alpha = 
255) so 0.0.0 = 0.0.0.255 etc. This way color values in old code 
that doesn't explicitly define alpha values are still compatible.


If you are interested, try to compile and test a bit. Let me know 
if you see any issues. Thanks.

if it where a generic string handling function I'd agree with you... 
but its not... it has added meaning, it splits filesystem paths. 
 its not just a string.  if it where, I'd use parse or some tokenize 
func.

I see absolutely no merit in trying to make split-path act like a 
generic string handling func.  the point of the func is to separate 
folder and file into two parts.   to me it comes down to either you 
decide that when there is no data you invent a default, or use the 
internal one which is none, which works well with soooo many other 
funcs.  if there is no directory part in the path, do not try to 
find a suitable value for it... there is none... funny, even when 
trying to explain my point of view, the actual sentence reads almost 
like a line of rebol source.  :-)

MaxV: "This way you have to write very long commands to achieve the 
most simple tasks (show mybuttob/gob ... mybutton/gob/size). Is it 
just my impression?"


My guess is you are not using R3GUI correctly. If you are using the 
current included R3GUI styles you shouldn't be forced to write any 
SHOW commands at all(the SHOW command is considered 'internal' in 
R3GUI and shouldn't be used anyway). Just use the SET-FACE/GET-FACE 
api to make changes to the specific style.

In worst case (usually when some ON-GET/ON-SET handler is unfinished/incomplete 
in some style) you can either try to enhance/fix that style part 
or

if this is too difficult for you you can try to use SHOW-NOW <face> 
to really force 'show' on the specific element.

How do you like this "Implementation artefact":

f: make function! reduce [[x /local x-v y-v] body: [
	x-v: either error? try [get/any 'x] [
		"x does not have a value!"
	] [
		rejoin ["x: " mold/all :x]
	]
	y-v: either error? try [get/any 'y] [
		"y does not have a value"
	] [
		rejoin ["y: " mold/all :y]
	]
	print [x-v y-v]
]]

g: make function! reduce [[y /local x-v y-v] body]

>> f 1
x: 1 y: 1

Just for comparison, these results are from R2:

f: make function! [x /local x-v y-v] body: [
	x-v: either error? try [get 'x] [
		"x does not have a value"
	] [
		rejoin ["x: " mold/all :x]
	]
	y-v: either error? try [get 'y] [
		"y does not have a value"
	] [
		rejoin ["y: " mold/all :y]
	]
	print [x-v y-v]
	unless value? 'y [g 2]
]

g: make function! [y /local x-v y-v] body

>> f 1
x: 1 y does not have a value
x does not have a value y: 2

And I'd generally try to stay 64-bit aligned.