AltME groups: search

Pekr - "if we can't have full fledged debugger, then we are crap 
:-)"

Agreed, though maybe not complete crap.


Brian - "Heck, even good old print statement debugging would work."

Agreed, to an extent.

Brian - "They could even be trace events."


Ahhh, joy. What can we learn from DTrace, and what should modern 
debugging look like? I have, at times, ached for the ability to step-trace 
and set break and watch points in REBOL. At the same time, I don't 
want to be myopic and focus on how we debugged in the past.


What are the best ways to debug the things we're supposed to build 
with REBOL? And can we hope for mechanisms to let us debug things 
outside what RT says REBOL is targeted at?

using replacement function builders we could, in theory, completely 
control how execution occurs.  this would be at some speed cost and 
possibly not 100% transparent.


but setting break points and real-time value watching is definitely 
in the realms of possibility.

I just don't want to preclude the use of R3 in the biggest industry: 
content delivery and presentation.

I've got this unexpected R3 behaviour (it's the core of the LDS issue 
mentioned in [Testing and Tools]

    f: func [] [error? try [return 1] return 2]
    f
    == 2   ;; r3 does this....despite no error
    == 1   ;; r2 does this...as expected

Any ideas, thanks!

Anyway, 'read is a straight 'GET and write allows custom headers

I haven't looked to see how it handles PUT, and DELETE with parameters

That was a heck of a coding and debugging session we just got through. 
Alpha 108 is going to be really cool :)

have a lot of things changed wrt the host-kit structure and its files?

I don't know about that yet, I just worked on core builds. Afaik 
there are no major changes to the host kit APIs in this release. 
Only major system structure and semantic changes in R3 itself. And 
a new module system with all sorts of fun tricks available. And some 
fun minor changes to some natives and mezzanines, plus some major 
changes to a few other mezzanines.

I use .r3 for REBOL3 scripts and .r for R2.

I think, that the majority of REBOL scripts are .r and they work 
in both R2 as well as in R3

If someone close to Carl could ask him to release A108 as both binary 
and hostkit, that would be much appreciated.

...first. Your concerns (and those of others) have been noted and 
passed along. But the plan will be set based on the stability of 
the core release.

Or it is not, and RT builts from separate sources.

Most of the host kit problems that end users find and Rt doesn't 
are compiler or platform related, not due to source differences.

Just release pre-built binaries along with the hostkit, and let users 
test however they wish.

Nothing changed except everything that is REBOL-related, and the 
module system that extensions are built on.

You will be able to test the A108 changes quite easily without a 
host kit. Extensions can still be loaded externally, and the rest 
is core.

And this is the biggest core change in the last year. It needs extra 
testing.

I meant to say that I was starting work on the *release* itself (preping 
and cleanup folders of bogus files, and basically uprooting the current 
compilation setup into new clean folders, while doing a little bit 
of diffing on the released A107 to see if any oddities have crept 
in the code.

The header changes in A108 will be ignored by A107, and the old settings 
will be ignored by A108, so if you want to have transitional code 
you can use both. The only change that I know is not automatically 
adjusted for is the isolate: true header, so if you need that and 
want it to also be compatible with A108 then also include options: 
[isolate]. And you don't need to use type: 'extension anymore, type: 
'module will do (in either version). Don't use the word 'hidden in 
your modules though, at least not at the top level - hidden will 
be a new keyword in module code, like export.

Except for the 7 month hiatus between the first hostkit release and 
the second.

The situation is different now, and has been for the last 10 releases 
at least.

And my time is free now. I work on the core, not really the host 
kit much yet. However, I must run an errand. Later :)

And obviously it takes some time for him to disentangle that from 
what is externally released, along with some copy/pasting and what 
not.

Nope. Internal testing has to pass before any release. And the subset 
of code that I know that has passed internal testing is the subset 
used by the core binary. Even a core hostkit release has more code 
to test than a core binary release.

For instance, we only have a Windows build for now. A host-kit release 
includes the sources for all supported platforms, even if it doesn't 
include the binaries. And that source would need to be adapted to 
match the new system model to be included in a release. As of when 
last I checked, we hadn't adapted the Linux-specific stuff yet. No 
changes may be needed, but without test builds, internal testing 
of those builds, and debugging we can't say for sure that the extra 
code in the host kit release is of even alpha release quality, no 
matter if we mark it as experimental.

No, core works for me for now, and all of my contributions in the 
recent round have been mezzanine, and native testing. I'll start 
working on the higher-level host kit code more when the lower-level 
code I have been working on is done.

I have been following the discussions of the people designing and 
implementing it. And I have read the host code source.

Please redownload the Windows build. An obscure bug and a last-minute 
convenience fix were just added.

so the * finds the first match and uses it ...

and as part of the language?

so I could use a function that traverses the object doing string 
comparisons and returns the full path for me so I don't have to keep 
typing it

These your tests? And did you redownload the build?

Yeah, and in the docstring.

Just looked back and we made that change in 2008. Wow.

Seems complement no longer works on images and silently fails.

And 75, 101, 102.

AS are 135-137 and 138-141.

And 150-152, 153-156.

Ok, and that's it.

Ok, 108 introduces 4 new errors (bad-header, bad-checksum, no-script, 
invalid-port-arg), renames 1 (bad-intrinsic to bad-sys-func) and 
changes the number of arguments for 1 (security-error)

And the error in 11 was renamed, as stated above.

We had a CC issue for that, and the result was adding the error code 
checking to make error!.

Something changed between A107 and A108.

** script error
 and "** Script error" are fatally similar.

Or it was "unfixed" somewhen between A98 and A107 :)

Hmm, A98 had the same behaviour as A107, for both `to error!` and 
`make error!`.

While you are at it, please reopen bug#1667 and bug#1679, both of 
which are not really fixed in A108.

As far as I remember, there are blocks with a length field, and blocks 
without (where you'll need to skip thru encoded the characters).

yep... AFAIK, that single thread and then nothing ever again until 
he pops up on CC and starts debugging like a mad man  ;-).  

I mean he is really low-profile.

I guess some people talk about things and others just do them.

others do both and don't get the time to release  them  ;-)

notice that I've recently released a few things quickly and this 
thread is just going to continue  :-)

Wow, Christian took my advice, and redo ODBC extension into .DLL 
form, and now it uses ports! That is cool. Should be imo reported 
to rebolweek :-) 

http://www.diefettenjahresindvorbei.de/odbc/odbc-docs.html

And I've taken your advice to publish a .dll, too. Somestimes, yeah, 
sometimes, I take advice ...

funny, it didn't register in my brain that the ODBC driver was for 
R3 and that it meant I could actually use it for work in a little 
while.. hehehe.   thanks !

Just posted a bunch of new CC tickets that explain a lot of the new 
or changed features in A108 and A109.
- New features in A108: 1682 1683 1684 1687 1690 1691 1692 1693

- New features in A108 that don't work yet: 1685 1686 (because of 
1685) 1688 1689 1696 (because of 1697)

- New features for A109 that I've already written: 1680 1681 1685 
1689 1694 1695 1696 (workaround)

Just a little tidbit I thought might be good for others still resisting 
the dark side of the force (R3 :-)


I'm at a point where I'm 50:50 in my time spend on R2 and R3 overall. 
which is a nice observation.

ATM, I much prefer R3 for many reasons.

-binding control and dynamic code building is soooo much better.
-embeded modules
-extensions which can (at last) almost do anything with REBOL.

-being able to fix/understand some limitations myself by "looking 
under the hood".

-it really is much better designed, scalable, fast, consistent and 
more.

why is R3 the dark-side?
-it constantly tempts you, 

-promises power (which it ultimately delivers, after kicking you 
in the nuts a few times), 

-allows much easier access to evil dlls (dark lawless libraries) 
than R2, 

-can be a lot more harsh finding your errors, but then removes guilt 
by disarming them 
-some unexpected issues still make it highly temperamental. 
-it will actually KILL your app with mush less discrimination 

-DOS shell makes it a trial by pain experience (and no, making its 
bg color white doesn't changes this ;-)

And this had to be bold why exactly?

I forgive max for his last bullet point: "DOS shell makes it a trial 
by pain experience (and no, making its bg color white doesn't changes 
this ;-) " - hehe, made my day :-)

so as for me - f*ck off MS shell crap, this is absolutly devastating 
experience for me, and they should fire someone in MS for that rude 
experience :-)))

Combine this with rlwrap, and you should have a usable environment.

pekr, its a console application, just like our current R3 CLI.   
a console is simply a place which accepts lines of input interactively 
and spawns processing upon hitting a complete command.

Andreas - power console can't work. I tried Console2. The outcome 
is, you can't have both the true console mode and the GUI app. Look 
at the above link. Or simply Carl was not able to achieve that. Some 
ppl said, that is the reason why Python has two executables - one 
for plain console mode, and the other for GUI mode. But I might not 
interpret it correctly ...

coundn't we just use their better console handling code and use it 
within R3's input loop?  or is that part of what you really meant?

yes? then we should take car to make it work with real console. I 
don't need power-shell. Shell2 is nice and sufficient. Simply - anything 
better than MS default console, is a win ...

how should I test? launch cmd.exe, and type R3? :-)

nooo, A107 ... and btw - what about that security dialog? Still no 
answer why it happens ...

tried A108 from console, and got:

** Script error: clean-path word is not bound to a context
** Where: if -applier-

** Near: if slash <> first boot [boot: clean-path boot] home: file: 
f...

Would you be so kind and try http://bolka.at/2010/rebol3/r3-a107-20100913.exe
instead?

Pekr, we found that error too and fixed it for the next release.

And yes as well, until R3 gets an R2-style REBOL console, building 
it as Win32 console executable might be worth it.

from my experience, if I build R3 as 'console app' the win console 
(the way it is handled now)  doesn't render characters in unicode. 
So far I haven't found a way how to fix that (and after brief googling 
the net it looks this is known issue)

imo, for the 'console app'  version you would need to use different 
approach...detect if the process already have console attached and 
the reuse it. But I  haven't looked into any details so it is possible 
even this won't work well.

ok, that is in the 'console app' mode....sorry I meant that there 
might be a way how to check if the 'GUI app' is run standalone or 
from console and then decide what approach to use. But I haven't 
tried to play with it yet.

you can try to attach to the console of the parent process, but carl 
seems to have tried that and it is now disabled for some reason.

They are working on Linux and host kit issues now (for European sleep 
schedule values of now).

The mix of mutating and non-mutating series functions sometimes really 
is maddening. Not to mention the uglyness of the resulting code.

yes, I agree, but therefore it needs to be clear which function modifies 
and which one does not:

? modifies

I also think we could use a document that states why some of the 
functions modify and some copy. I had a longer discussion about UNIQUE 
recently.

For those who worry more about elegance and conciseness than about 
performance ...

That can be a doc string convention and it would work just as well. 
We have already put (modifies) in a lot of doc strings.

(and perhaps some of the files not quite right either... so, it's 
not official.)

Other than that, the hostkit works fine (and hostkit-built binarries 
pass the same number of tests as the RT binaries).

Thanks, Ladislav.

There are several anomalies, which at least could be noted in the 
documentation under the pair! data type.


Another [anomaly]/[undocumented change from R2 behaviour] is when 
a pair overflows:

....R2 throws an error, or replacee the large number with 0 (itself 
an odd behaviour).

....R3 can generate +/-infinity. As far as I know this is the only 
way in R3 to get a -/-INF; and the value is not usably serialisable:
    xx: as-pair -1e44 1e44
    == -1.#INFx1.#INF
    type? first xx
    == decimal!
    load mold first xx
    ** Syntax error: invalid "integer" -- "-1.#INF"

INFs (and NANs) are part of the standards REBOL is coded to. It's 
good to match as much of the standard as possible.

REBOL clearly uses parts of the standard -- raising errors! rather 
than returning NANs or INFs is generally a useful approach for most 
programmers.

But, given it (now) partially implements INFs, some clarity about 
what parts (and why) would be useful too.

Pekr, Andreas, ChristianE and anyon who is interested...I published 
win console R3core version that should show correctly ut8 characters. 
IF you can try to dsiplay your native language chars just download 
it from here: http://cyphre.mysteria.cz/tests/r3-core-a107-console.zip
and let me know if it works for you.

Note that this version doesn't work well with STDIN/OUT redirection 
yet. I didn't want to waste time on this part yet until the normal 
console STDIN/OUT works well.

And it launches nicely from both a pre-existing console as well as 
from the explorer.

ok, what about having console (not GUI) build of R3, and loading 
View extension? Could it work?

yes ... that is why I am confused, because there was a saying, that 
under Windows, you can't have both worlds - console, and GUI app 
in one, and that e.g. even python uses two separate executables ...

Very good work. I confirm that under Vista (32 bit) it works well 
so far. Both from the icon, and from the cmd console. I don't even 
have to change fonts ...

Look at 1718 and 1720 too.

I think FORFIND was one (worse, and by me) suggestion, when Carl 
brought this up in a blog last year.

It is, and differently.

and a diff should really show all points of difference

And it is more exactly on topic than difference or diff.

and length? et cetera

Diverge is still a verb, and divergence still a nown. The dictionaries 
came later.