AltME groups: search

I mean like each application is forced to put its dependecies into 
specific folders within its install path.  this way you can very 
easily verify that things are wath they should, and can make OS lib 
calls which act with confidence.

Sorry, there's no user-specific folders under the install path, not 
without separate user folder permissions maintenance for each application, 
or those aliases you mentioned. Is it really so hard to put user 
files in user folders? You have to do that on Linuc and Mac...

That is platform-and-computer-specific. And the user files will be 
in a different place for each user - that's the whole point of them. 
Is it really so hard to put files in the standard user directories?

ICarii, AltME is currently a Win95 app (it puts its writable data 
files in the same directory as its program file) and it's written 
in R2.

brian, if windows actuall made the home directory something obvious 
and not tried to hide it in every conceivable way in the explorer 
I think the situation would be much better.


Vista/7  makes some of it better, then screws it up in another way... 
it just gets weirder at every release.

The only weirdness in Vista/7 comes from the need to support roaming 
profiles. Windows is built around multi-user, multi-computer use 
over a whole enterprise. It took them a while, but they are finally 
starting to get it right in Vista/7. The only sucky things come from 
having to run apps that don't play by the 10+-year-old rules. So, 
would you prefer that those workarounds be gone and not be able to 
run AltME on Vista/7?

I wish they had gone the OSX path and started fresh, with a built-in 
VM for XP/win2k support.

well, they just relax the enforcement... the rest of the os is still 
there... they still support most of the old api, its still just a 
tack-on more stuff and try to make it compatible again.  I know some 
of the kernel changed, but that doesn't really affect applications 
that much, since that is mostly doing stuff behind the API wall.

but they did rename and move a lot of things, for no purpose a part 
from annoying the hell out of everyone, still they are the same components.

And by aliasing in this case, I mean Unix-style symlinks. Only the 
new directory names are really there - the old, localized names are 
just symlinks.

And all because people keep hardcoding the English localized names 
instead of looking it up like they should.

anyhow... all I meant is that windows should have started from scratch, 
learn from past mistakes and build the leanest/cleanest OS they every 
built, instead we end up with an install which takes several GBs 
on disk and 2GBs of RAM minimum to run.

And then the uptake would have been nil. Remember, from a business 
standpoint the best feature of Windows is its ability to run Windows 
apps, even the crappy ones. Lose that ability, lose the upgraders.

Unless you don't want apps like AltME and other ones that act the 
way you have requested to run on Vista/7...

that's the point of having a full VM installed in the transition 
period.  yess it takes disk space, but at least you only keep the 
legacy things within the legacy environment.  they could have gone 
100% 64bit for example and not have to support 32 bit modes within 
the 64 bit and also distribute a 32 and 64 bit version, things like 
that where there are already many *current* apps which fail in one 
or the other.  my friend can't get her camera to work on windows 
7 cause its only compiled as a 32 bit app (drivers and all).  but 
she was forced to use a 64 bit win7 because of support issues.

this sounds like it should be in Windows and not here ...

We were discussing installation issues on Windows. Since writing 
an installer for Windows (and other platforms) is the current activity 
towards the next R2 release, it is the topic of the day here. Remember 
when I said I wanted feedback here? It fianlly arrived :)

what do you mean by "so that it executes" - just tried it and it 
seems to start...

First, thanks to Brian for making sure this gets done right (or at 
least the best we can given the circumstances :-). Getting the installer 
right is part of the battle, but another part is making sure we, 
as  developers, do the right thing as well. The effort to identify 
system direcories, and provide mezzanines to make it easy to use 
them correctly, benefits everyone.


The old Roxy installer code is all BSD, and I'm happy to provide 
it, even if just for fodder.

Brian: What would be one such "corresponding concept" and how would 
you use it from within REBOL? (Assuming that meant REBOL scripts 
by "scripts").

Yes, the sys-vars module in Roxy is a crude start on that, so you 
don't know about Documents and Settings versus ~ or Program Files 
versus /usr/local/bin.

What was always missing in R2 was the ability for a programmer to 
get system information in easy to use way.

user-name (actuall real login of running task)
user home and related dirs

things like that which should be in the next release, especially 
if you are going to rummage through all of this.


I used routines to get to some of this, but I think it would be nice 
if this was built-in.

Andreas, corresponding concepts:
- The place where the program is installed/located.

- The place where the installed program version is listed, so you 
can know whether an update is needed.

- The place where user files, particularly the view-root and desktop 
files, needs to go.

- The place where machine-specific user settings should go (console 
layout on Windows).

- File associations, where possible. Not assuming that these are 
possible on platforms other than Windows.


Where these go depends on the installation profile. Yes, not installing 
at all is one of those profiles.

Adrian, "so it executes"  I meant installing rebol in the OS via 
file extensions so it always uses the -qs arguments over and above 
those it gets from the explorer.


also can shortcuts have arguments in win7?  this was removed in vista.

Andreas, the installer determines these things at install time, and 
sets things up for the runtime. but the runtime has to look for stuff 
where the installer puts it, and previously R2's runtime looked in 
the wrong places.

and its a different place in many linuxes now.  :-(

And then where are the user files, such as the view desktop placed? 
And how does the runtime determine that?

right now, when we write REBOL apps, we are running blind.  its very 
complicated, and something most script coders will not put the time 
to learn.

Andreas, you are not getting that /View is not installed until viewtop 
can run properly. And that needs user directories, and font paths.

view and viewtop

Using Debian packaging as an example: you'd just have a rebol-view.deb 
which installs the binary. And another rebol-viewtop.deb which installs 
a script to launch to viewtop and depends on rebol-view being installed.

Maybe the disconnect here is that you are getting distracted by the 
word "installer" and not realizing is that what we are discussing 
is determining the places where stuff is put, both files and settings. 
And that the runtime needs to look for the same stuff in the same 
place where it is put. And that for Linux, it might be put there 
manually, but it still needs to find stuff at runtime.

The runtime is /View doing something other than installing itself. 
And it needs settings, cross-platform settings that are made available 
inside /View without any script needing to check the registry of 
call GET-ENV, for scripts to know where to put or look for the stuff 
they need to run.

and you cannot overide how IT wants to install in cases where you 
know exactly what YOU want it to do.  for rebol it wouldn't be too 
bad, but for scripts which are more than your little 100 line reblet, 
this gets VERY annoying real fast.

And what registry settings does it write?

They make a global install, but save the global settings in the user-specific 
locations, and the use-specific stuff in global locations.

On Linux, there's two versions of REBOL immediately available: /Core 
and /View. /Core is a REBOL binary w/o GUI capabilities, /View is 
a REBOL binary with GUI capabilities (and beyond that, it comes bundled 
with a self-installer and the Viewtop app).

as a reboler, I don't want to write system specific and environment 
 resolving code.  


my script should be able to ply itself to whatever system its installed 
on and still read/write its files in proper OS expected places.


This is what we are talking about Andreas... viewtop specifically 
has nothing to do with this.  this is for ALL scripts to be compliant.


if I had a command which allowed me to build a system-compliant "application 
data path" then it would write stuff in ~/application/ on linux and 
whatever profile/app data/application   path is being used by your 
flavour of windows.


right now, I'd have to write a library which determines this and 
it probably will screw up on ubuntu, or Mac Or the latest windows.

things like user names and user folders have to be extracted within 
a routine using proper OS calls, either WinAPi or Env values if that 
is what your OS uses.

And that is stuff the runtime should be doing, so that scripts can 
be cross-platform. Platform-specific stuff has no business being 
in scripts, or the mezzanine code for that matter.

the only sensible solution is to be mostly platform ignorant and 
build a rebol-specific packaging and distribution system. which, 
iirc, you did a few times in R2.

Then the runtime would still need to look stuff up from the platform, 
and put the answers in nice, cross-platform REBOL settings in system/options, 
system/user, etc.

adrian, when I edited the shortcut on vista, and added the arguments 
it wouldn't save it, telling me the path to the executable didn't 
exist  :-(

and yes... you have to manually change the command-line arguments, 
but then the OS' editors break up in what I can't remember, I think 
rebol disapeared from the "installed applications" list, although 
the file association still worked.

I don't have vista installed anymore... but i'd just go on the desktop 
and right-click, create shortcut.

if you try to change the read-only property of files/folders they 
aren't actually applied, it was listed as a bug on severl IT sits 
on the net.  

basically, many applications suddendly coudn't write to folders anymore. 
 I had problems with rebol in SOME paths.

I even had issues with xcopy!  


looking at the files in a shell, they where all listed as read-only 
and couldn't be set to anything else... (this wasn't within windows 
folders, but on a data disk, before you ask ;-)

Haven't seen that yet. But I almost never use Vista, and rarely XP 
for that matter now, just 7.

but I kept on unchecking the read only prop, applying the change 
which asked to apply to all children and I said yes, it looked like 
it was recursing and setting the flags - then I exited the dialog, 
and upon re-checking, the settings seemed to be the same as before

its not *supposed* to be an issue, but I have had issues where it 
was.  I had read on the net and others where also having write issues 
on their data disks.  it as even flagged at a MS site... buts been 
a while (like 3 years) so I don't remember all the details of the 
problem.

Graham, the id in your link is negative(!), and gives this:
	ERROR: Ticket not found. Go back and check your input.

Before a RAMBO ticket is reviewed and accepted it has a negative 
ID. If it doesn't work now, it must have been reviewed. Don't know 
the current ID.

Right. And once I figure out how to make it not do so in R3 (based 
on Gabriele's code) then I will port that to R2.

Perhaps DECODE-URL should dehex the split-out parts, but after it 
splits them out. And since it doesn't fully decode the path section, 
it shouldn't dehex it - and probably not dehex the rest, just for 
consistency. If the reconstructed url doesn't rehex the parts then 
it shouldn't dehex them in the first place.

If you feed a url to a function, the only thing you really need to 
dehex is the username and password... nothing else

Well, DECODE-URL should probably not dehex the username and password 
unless the (unknown to me) code that reassembles the url! can be 
changed to rehex them. As it should, but I don't know which code 
to fix. The scheme, host and path should not be dehexed in any case.

The problem is that while the scheme might not represent anything 
network-related, the standard for URI syntax is independent of network 
issues. And that standard is pretty strict about hex encoding, regardless 
of the scheme's internal rules. So schemes need to be hex-encoding-aware 
for their specs, whether they are network-related or not.

brian, true.  my error... I'm deep in calculus... my brain is a bit 
mushy ;-)


IIRC the RFC has an BNF-style breakdown, so there should be no surprise 
as to where hexing can and should be interpreted.

but I remember having the same issue a while back and traced it to 
the actual datatype always handling the hex values.

in my app, I ended up doing all URL manipulation in strings, and 
then just converting to url at the time of network call

IMHO the datatype can't know when. only the schemes and url processors 
know "when" is appropriate.

just tried a read, and when the second form of graham's test (using 
to-url on a string) the url parser doesn't dehex... so the username 
will be invalid.

ok so then the dehexing should be added in the url-parser and string 
notation used for @ containing passwords.  

just like we use string notation for files containing spaces.

Excellent summary Gabriele. Thanks for posting that. It makes the 
problem and solution very clear.

Personaly I think putting out some test builds is always a good thing, 
 and the prudent thing to to is to make them available for the most 
popular platforms, best chance of someone doing something that results 
in useful feed back. unfortunatly as a unpopular platform user that 
means I am out.

This is one reason why I wrote a rest protocol.  The http protocol 
seems designed to get content the same way a browser would.  But 
as more services use http more completely, things like automatic 
redirects and thrown errors for 4xx/5xx status codes are not helpful 
(and good luck getting headers and content then).

Yeah, and then monthly releases

That's ok, but in profressionnal world even if the main project is 
R3, R2 is the main product. And you need to see bug fixes, supports 
and so forth.

You need compatibility with Windows7, new version of Linux and MacOSX.
And what about Windows Phone ?

Most of what is needed for Windows 7 compatibility was also needed 
for Windows 2000 compatibility (I reported it then), and mostly in 
the /View installer and registry usage. That installer is in the 
community-supported portion of R2, so if you download the SDK source 
you can take a look. The installer changes are intended for inclusion 
in 2.7.8, as the changes doc indicates.

And from the 2.7.8 channel .. from April

The problem with R2 bugfixing is, that only Carl can patch the code.. 
and Carl is in a cave mode again... or travelling around the world 
:-)

I think that Carl, Gabriele or BrianH can give you R2-beta access. 
If you need to report R2 bug, you can use any (not R3 related) group 
here and submit it into Rambo.

I think the r2-beta world can go alive again if Carl would like to 
participate and next round of the R2 improvement.

The main difference between r2-beta and this world is, that it's 
allowed to upload files on r2-beta and it was used to give us pre-official 
releases.

We've been working on 2.7.8 today, and the test builds look good. 
New stuff coming from R2/Forward :)

And hope the design of View will be refreshed as what has been bone 
by Carl in march !
Cool design !
http://www.rebol.com/r3/docs/gui/guide.html

nve - that will not simply happen imo. And even Carl's experimental 
skin (which I initially did not like) is no more available to even 
R3 View. So far we have got ugly glossy hybrid skin, which is here 
to ease development, so definitelly not final :-)

Refreshing R2 View is a huge amount of work (I spent almost a year 
building an extension of it) and IMHO not worth it. The look of R2 
View is one of its smaller problems.

The look of R2 View is one of its smaller problems.

 => OK, but we are in 2011 (already for some, in a couple of hours 
 for the others).

An look is important. Apple and Steve Jobs show how it is important.

A good look will be possible for R3 to do. It's simply a waste of 
time for R2 and you can't produce anything that resembles Aqua anyway 
in R2. In R3 that is possible. But focusing on look alone is a big 
mistake, which too many developers using GUI systems are suffering 
under.

nve - what is Henrik trying to point out imo, is the fact, that it 
is not that easy to change look of R2 VID and stay consistent. I 
think that with VID3 it is going to be easier, as the system is more 
and better abstracted. It might be easier to do the job for R3, than 
to R2. I believe R3 is going into beta sometimes ... when Carl re-appears 
 + 2-3 months :-)

Rebol2 is quite a closed project. It needs only maintaining and updating 
activity. No more core changes.

Some of what is coming in 2.7.8:

- Bug fixes and enhancements to improve Cheyenne, and other apps 
that have to do similar stuff.

- Some native fixes for non-Windows platforms, particularly Linux.

- Environment variable stuff: GET-ENV expansion on Windows, SET-ENV, 
LIST-ENV

- Function fixes: RUN enabled, LIST-REG/values, possibly TO-LOCAL-FILE

- R2/Forward: FUNCT/extern, LAST?, COLLECT-WORDS, EXTRACT fixes, 
ASCII? fixes, LATIN1? fixes, INVALID-UTF?, CD, LS, MORE, PWD, RM

- (Still pending) Natives: ASSERT, APPLY, RESOLVE, FOREACH set-word 
support

Some of the registry stuff is broken on R2/command .. hope they are 
fixed and not just enabled

One of the things we would like to do is easily detect all installed 
fonts in windows, and install new fonts

And from View in Sept 26

and ...


keys: list-reg/HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts"
    probe keys


    keys: get-reg/HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" 
    "URW Palladio L Italic (TrueType)"
    probe keys


    keys: exists-reg?/HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts\URW 
    Palladio L Italic (TrueType)" 
    probe keys

produces this

[]
URWPA32_0.TTF
false

At least for Windows so far. Things that didn't make it in this version:
- The TO-LOCAL-FILE fix for Windows UNC paths
- FOREACH set-word support
- ASSERT, APPLY and RESOLVE are still mezzanine

But as a bonus, we got SELECT and FIND on objects, and that is better 
than any of those others :)

and for linux ?????

Btw.. it would be nice to port the bugs from old tired Rambo to the 
CureCode hospital, where it's pretty visible which bug is fixed and 
if the fix is tested as well.

What we got in 2.7.8, that I know of:

- Bug fixes and enhancements to improve Cheyenne, and other apps 
that have to do similar stuff.

- Some native fixes for non-Windows platforms, particularly Linux. 
See ACCESS-OS.

- Environment variable stuff: GET-ENV expansion on Windows, SET-ENV, 
LIST-ENV

- Function fixes: SELECT object!, FIND object!, RUN enabled, LIST-REG/values

- R2/Forward: FUNCT/extern, LAST?, COLLECT-WORDS, RESOLVE, APPLY 
fixes, EXTRACT fixes, ASCII? fixes, LATIN1? fixes, INVALID-UTF?, 
CD, LS, MORE, PWD, RM

As R3 has no official release still in alpha mode and because there's 
a big shift between R2 and R3, professionnals user's of REBOL really 
need to have a plan for R2 support, R2 bug fixes, R2 enhancement...

Is there's something to migrate script written in R2 to script in 
R3 ?

We have a few plans for R2 enhancement, mostly the View installer 
on Windows, but for the most part we are just backporting enhancements 
from R3 whenever we can and they are backwards compatible. Bug fixes 
and additions, no big changes, that is the policy. R2 is in backwards-compatibility 
mode as a rule.

On my windows XP SP3 the VIEW is failing as invalid exe; the CORE 
is fine;  these are both numbered 3.1 for 2.7.8 and no change with 
fresh download; the inspected exe is not garbage but kicks this error 
whether in open cmd session console or fired by explorer - I did 
not try under Cygwin or MSys yet ...

Here on XP SP3 all of the exes, including View, Core and the SDK 
programs all work. Have you tried redownloading and reextracting? 
Are there other system settings or software that you have that might 
affect this? Which antimalware or firewall apps are you using?

one indicator: IE 8 (which is not my default now since I moved to 
K-mleon) runs VIEW 2.7.8 as a right-click option using RUN - but 
download with IE8 and run from Explorer file view correctly triggers 
a request to authorize due to no "valid" digital signature for MS 
- yet this MS alert fails to trigger when run after download using 
K-meleon browser (yet no issue after K-meleon downloads CORE 2.7.8 
)

this is a K-Meleon Windows browser gift  - maybe sometimes smaller/faster 
is not better ... KMeleon is writing to a USB ext drive and IE8 is 
writing to an internal HD ... sometimes KM is writing the larger 
VIEW exe intact, sometimes not.  This may account for some recent 
"bad" ZIP's from my x-plane Flightsim community.  Yuch.  Most of 
 those x-p guys always zip up all their Win indexing .Thumb or hidden 
Mac files - and sometimes they have accumulated both from working 
on a Win "airplane" on their Mac. So I am used to annoying ZIP's 
for that hobby ... but this is TOO annoying.

The request-to-authorize thing is managed by an extended attribute 
in one of the other forks of the file on NTFS, and not on FAT. Have 
you tried Chrome or Firefox?

Looks like we have OSX Intel and Linux Libc6 builds now.

2.7.7 also turned out to have to be a minimal release at the time. 
It's hard to budget time for major native changes in R2, partly due 
to business constraints (who is paying for this work? noone that 
I know of, and adding Library to Core removes a revenue source without 
replacing it with another), and partly due to the nature of the codebase 
itself.

Yes, Doc, I have been requesting that too. And Carl (belatedly) said 
to hold off on using or announcing the SDK (don't know why).

That's your perogative, since you haven't seen the code, and haven't 
discussed the code with Carl.