How to request a new version on a specific platform?
[1/18] from: brainlai1102:gm:ail at: 3-Aug-2006 23:58
Dear all:
The ftp(exists? and directory port operation fails) and smtp(no auth or
attachment) malfunction on mips platform where only 2.5.1 is available. I
try the feedback mechanism provided by REBOL.com to request a new version
2.6.x on a specific platform(mips linux), but do not receive any reply for a
couple of weeks.
Since REBOL is closed source, how do I get any help instead of just waiting
and waiting again?
BR.
Brain Lai
[2/18] from: greggirwin::mindspring::com at: 3-Aug-2006 10:58
Hi Brain,
BL> The ftp(exists? and directory port operation fails) and smtp(no auth or
BL> attachment) malfunction on mips platform where only 2.5.1 is available. I
BL> try the feedback mechanism provided by REBOL.com to request a new version
BL> 2.6.x on a specific platform(mips linux), but do not receive any reply for a
BL> couple of weeks.
You may need to patch in mezzanines and protocol updates where you
can. RT doesn't keep up with builds on OSs where the demand is low. It
sounds like your issues can be addressed without a new build from RT
though.
-- Gregg
[3/18] from: volker:nitsch:gmai:l at: 3-Aug-2006 19:32
On 8/3/06, Gregg Irwin <greggirwin-mindspring.com> wrote:
> Hi Brain,
> BL> The ftp(exists? and directory port operation fails) and smtp(no auth or
<<quoted lines omitted: 6>>
> sounds like your issues can be addressed without a new build from RT
> though.
You should add that everything above tcp/ip is practically open source ;)
Written in rebol and rebol can be converted back to sourcecode.
It may even be possible to save the 2.6.2-protocols and load them in 2.5.1,
i do not know how much they changed.
Doing that i leave to the people who are more familiar with protocols ;)
> -- Gregg
>
> --
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
>
--
-Volker
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.
David
Wheeler
[4/18] from: greggirwin:mindspring at: 3-Aug-2006 11:50
VN> You should add that everything above tcp/ip is practically open source ;)
VN> Written in rebol and rebol can be converted back to sourcecode.
Yes, thanks Volker.
-- Gregg
[5/18] from: brainlai1102:gm:ail at: 4-Aug-2006 2:06
Dear Mr. Gregg:
Thanks for your reply.
However, I don't understand what you mean "the demand is low." One shall ask
what demand is high. So far the release of version 2.6.x just supports
several so-called major desktop OS and platforms, especially x86
architecture. Are these enough to demonstrate REBOL's portability? If people
sees no portability, who demands REBOL?
For most developers diving into embedded systems, they even don't knnow what
REBOL is about. Event if some of them try REBOL a few times, they cannot
still make sure REBOL's continuous support for miscellaneous embedded
systems such as ARM, 68K, BSP, MIPS, RISC and etc. The future looks so
unclear. The only thing obvious is that no availablity no portability. A
conclusion is reached: come back to C/C++ rather than figure out what
mezzanines and protocol malfunction since C/C++'s availability is
undoutedly nonesuch.
Slim and lightweight are more advantageous in embedded systems than on
desktop. But once again: no availability no advantage.
Sorry to complain the truth. I just feel disappointed because it should be a
piece of cake to build new releases for other platforms.
--Brain Lai
[6/18] from: jblake:arsenaldigital at: 3-Aug-2006 14:20
I just feel disappointed because it should be a
piece of cake to build new releases for other platforms.
Interesting. I am trying Rebol because I thought it was portable.
Portable as in the same thing can be loaded on all OS's supported.
Are you guys saying it cant be loaded on all those OS's without
downloading a code for each OS?
I must be misunderstanding something.
John
[7/18] from: greggirwin:mindspring at: 3-Aug-2006 12:27
Hi Brain,
BL> However, I don't understand what you mean "the demand is low."
I just mean that if <1% of people are requesting builds for a
particular OS, it may not be worth their effort to keep builds updated
on that platform.
BL> So far the release of version 2.6.x just supports several
BL> so-called major desktop OS and platforms, especially x86
BL> architecture. Are these enough to demonstrate REBOL's portability?
For better or worse, I think portability isn't as important as it used
to be to RT (just my opinion). If you can reach 98% of the people by
supporting two or three platforms, you need a compelling reason to
maintain support for 40 other platforms, each accounting for .05% of
your target market. It may also depend on who is paying for REBOL, and
who is using the free versions (platform-wise).
BL> Sorry to complain the truth. I just feel disappointed because it
BL> should be a piece of cake to build new releases for other
BL> platforms.
Only RT can speak to how easy it is, but my guess is that it takes a
huge amount of effort to keep builds up for the number of OSs they
actively supported at one point; in large part because it's
proprietary.
-- Gregg
[8/18] from: greggirwin:mindspring at: 3-Aug-2006 12:32
Hi John,
JB> Interesting. I am trying Rebol because I thought it was portable.
JB> Portable as in the same thing can be loaded on all OS's supported.
JB> Are you guys saying it cant be loaded on all those OS's without
JB> downloading a code for each OS?
REBOL code is portable; the REBOL VM/interpreter has to be built for
each platform. Brain's issue is that the build for his OS (Linux/Mips)
isn't currently kept up by RT.
-- Gregg
[9/18] from: volker:nitsch:gmai:l at: 3-Aug-2006 21:04
On 8/3/06, Brain Lai <brainlai1102-gmail.com> wrote:
> Dear Mr. Gregg:
>
> Thanks for your reply.
>
> However, I don't understand what you mean "the demand is low." One shall ask
> what demand is high.
I am no insider, as far as i know:
Sometimes demand of the form "Hey RT, can you build for platform X?" is enough.
But currently RT is busy with a major rewrite and stretching its manpower.
> So far the release of version 2.6.x just supports
> several so-called major desktop OS and platforms, especially x86
> architecture. Are these enough to demonstrate REBOL's portability? If people
> sees no portability, who demands REBOL?
Hum.. If it runs on windows, linux, mac, that demonstrates the
technical property.
But not in the "available"-sense. Not good, but manpower and priorities..
OTOH, if there is 2.5.* for mips, its not that different.
> For most developers diving into embedded systems, they even don't knnow what
> REBOL is about. Event if some of them try REBOL a few times, they cannot
<<quoted lines omitted: 4>>
> mezzanines and protocol malfunction since C/C++'s availability is
> undoutedly nonesuch.
Embedded seems not to be a high priority at RT. Part of it is, the
binary is small, but it needs some MB of ram for internal things, so
the footprint is somewhat big.
(for embedded, on desktops that amount is barely noticable).
Rebol3 wants to change that, less memory and better hooks to the
outside, so that "closed source" is a much smaller showstopper.
About c++, i guess its libraries have quirks too, and you have to
either fix that or find a workaround too.
> Slim and lightweight are more advantageous in embedded systems than on
> desktop. But once again: no availability no advantage.
>
> Sorry to complain the truth. I just feel disappointed because it should be a
> piece of cake to build new releases for other platforms.
>
Setting up the rarely used platform and adjusting some makefiles may
take a few hours. + some testing.
> --Brain Lai
>
> --
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
>
--
-Volker
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.
David
Wheeler
[10/18] from: brainlai1102:g:mail at: 4-Aug-2006 3:30
Dear Sir:
Something I may not mention clearly...
The truth seems that while REBOL code is portable, the REBOL VM/interpreter
is not.
My problem is not just that the build for my OS (Linux/Mips) isn't currently
kept up by RT.
Actually, I found the same scritps (ftp/smtp operations) work on linux/x86
but not on linux/mips. The same syntax leads to different behaviors. No
protability anymore.
BTW, desktop might be major but definitely not anywhere as embedded systems
in the world.
--Brain Lai
2006/8/4, Gregg Irwin <greggirwin-mindspring.com>:
[11/18] from: brainlai1102:g:mail at: 4-Aug-2006 3:40
> About c++, i guess its libraries have quirks too, and you have to
> either fix that or find a workaround too.
At least, we have the library sources. The porting process is not mission
impossible!
Setting up the rarely used platform and adjusting some makefiles may
> take a few hours. + some testing.
Why not open this time-consuming tasks to the community? If RT determine to
close source, it should be responsible for that tasks. Is it not imperative
for a commercial company to be always prepared?
--Brain Lai
[12/18] from: tim-johnsons::web::com at: 3-Aug-2006 11:27
* John Blake <jblake-arsenaldigital.com> [060803 10:40]:
> " I just feel disappointed because it should be a
> piece of cake to build new releases for other platforms."
<<quoted lines omitted: 3>>
> downloading a code for each OS?
> I must be misunderstanding something.
Hi John:
The rebol binary is an interpreter. It is in fact an application
that must be compiled for the target OS.
On the other hand the rebol code itself is for the most part
portable.
If you are writing rebol code for CGI scripting the '#!' line
may need to be taken into consideration as the path to and the
name of the binary can be different on different OS.
Example: on Windows: the rebol binary is named "rebol.exe" on
*nix systems it is "rebol" (no extension).
Everything I have stated here applies to other scripting (interpreted)
languages like python, perl, ruby et al.
HTW
tim
> John
> -----Original Message-----
<<quoted lines omitted: 35>>
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
--
Tim Johnson <tim-johnsons-web.com>
http://www.alaska-internet-solutions.com
[13/18] from: volker:nitsch:gmai:l at: 3-Aug-2006 23:36
On 8/3/06, Brain Lai <brainlai1102-gmail.com> wrote:
> >
> > About c++, i guess its libraries have quirks too, and you have to
> > either fix that or find a workaround too.
>
> At least, we have the library sources. The porting process is not mission
> impossible!
>
Same goes for rebol. As i said, that part of the source is open.
Some people here patch it all the time.
> Setting up the rarely used platform and adjusting some makefiles may
> > take a few hours. + some testing.
>
> Why not open this time-consuming tasks to the community?
To have some way to force people to pay, or to prevent forks, or
something i overlook.
> If RT determine to
> close source, it should be responsible for that tasks. Is it not imperative
> for a commercial company to be always prepared?
>
To fix each and every bug? Outside of "mission critical" it would be
the first company which does that. The others look for their manpower
and set priorities. If customers are not happy with their choicest,
they may loose them of course.
> --Brain Lai
>
--
-Volker
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.
David
Wheeler
[14/18] from: volker::nitsch::gmail::com at: 3-Aug-2006 23:40
On 8/3/06, Brain Lai <brainlai1102-gmail.com> wrote:
> Dear Sir:
>
> Something I may not mention clearly...
>
> The truth seems that while REBOL code is portable, the REBOL VM/interpreter
> is not.
It is c, so as portable as c. Just not for us.
> My problem is not just that the build for my OS (Linux/Mips) isn't currently
> kept up by RT.
> Actually, I found the same scritps (ftp/smtp operations) work on linux/x86
> but not on linux/mips. The same syntax leads to different behaviors. No
> protability anymore.
One is 2.5, the other 2.6. There are bugfixes. If you find a 2.5 for
x86 i guess it behaves the same.
> BTW, desktop might be major but definitely not anywhere as embedded systems
> in the world.
<<quoted lines omitted: 18>>
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
--
-Volker
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.
David
Wheeler
[15/18] from: brainlai1102:gm:ail at: 4-Aug-2006 10:29
> > The truth seems that while REBOL code is portable, the REBOL
> VM/interpreter
> > is not.
>
> It is c, so as portable as c. Just not for us.
Once again, no availability no portability. C/C++ is more available than
REBOL on any platform(BOTH compliers and sources) while REBOL code is not
portable anymore due to the inavailability of its interpreter and
incompatibility issues between different versions. If people do not consider
the availability of REBOL VM/interpreter, the sentence "REBOL code is
portable" is easy to mislead people.
> My problem is not just that the build for my OS (Linux/Mips) isn't
> currently
<<quoted lines omitted: 5>>
> One is 2.5, the other 2.6. There are bugfixes. If you find a 2.5 for
> x86 i guess it behaves the same.
Who should take the responsibilty for the incompatibility when version
evolves? The user or RT?
In fact, the official RT web site says: REBOL is small, PORTABLE, and easy
to manage. If this claim applies just to REBOL code instead of its
interpreter, REBOL sounds just more practical than the mystical man-month.
--Brain Lai
[16/18] from: petr:krenzelok:trz:cz at: 4-Aug-2006 11:52
Brain Lai napsal(a):
>>> The truth seems that while REBOL code is portable, the REBOL
>>>
<<quoted lines omitted: 10>>
> the availability of REBOL VM/interpreter, the sentence "REBOL code is
> portable" is easy to mislead people.
Brian,
I don't want to offend you, but what you actually are showing here, can
be called a trolling. PPL here tried to provide you with the clear
answers, yet I can see, that your concern is the only one - REBOL is not
open sourced, so it sucks ;-) I think that incompatibilities between
various rebol versions are kind of minor, mainly in mezzanine level,
and it CAN be solved imo. I have not heard much complaints in that
regard yet. So - I still consider rebol code kind of portable, although
I use only x86 Linux and Windows versions.
As for ability to port, someone already said it here - have you asked RT
to do so? They have to see some demand, or they have other things to do.
Btw - there is open-source attempt to clone REBOL, called Orca. If you
wish, you can help those ppl to have open-sourced REBOL.
I am not sure, but you seem to completly ignore one fact - RT clearly
stated, they moved all their resources towards bringing us REBOL 3,
which is supposed to bring us much more robust infrastructure. One of
the points is also an easier portability. So, just a bit of patience,
no? Not much is going to change in regards to R2 development branch
portability. As I said, you can try to contact RT to have official
answer, or you will have to look for some other tool, if REBOL does not
fit your needs properly, I think that is quite normal and natural ....
... as for me, looking forward to R3 alpha release, although already it
is late on schedule :-)
Cheers,
-pekr-
[17/18] from: brainlai1102::gmail::com at: 4-Aug-2006 22:00
Dear pekr:
Anyone can feel free to offend me if more about the truth is revealed. I've
send my request to RT by applying their official feekback mechanism for
weeks. No reply from the commercial company yet(maybe I should pay for that?
Since all the resources are moved to R3, nothing is left for the free users
^O^). Hence, I decide to post message here to figure out wha't going on.
So far, I can't still recognize if there is anyone here representing RT to
show the official attitude towards portability(quite essential to embedded
systems). All the answers such as the demand is high/low, the porting
process is easy/hard and etc. sound like just a little bit of guesses and
assumptions. Since REBOL is close source, the official attitude absolutely
influences its future and one's evaluation whether to pay for it or not.
The official RT web site claims REBOL is portable. Those most clever
Rebolers must design and implement with portability concern in mind, mustn't
they? A product is created with portability concern in mind but hard to
port in reality is also hard to believe.
The demand for embedded systems is not low at all but just miscellaneous.
That's where the real portability challenge to a language which claims it is
portable. It would be a joke if a language declares its portability but
supports fewer and fewer platforms with its version evolving.
BTW, I never mean REBOL sucks. I just realizes that a commercial company can
make its claim while lose the corresponding promise at the same time.
Basically, I respect any commercial companys which decide close source on
the premise that they must be confident of providing higher quality and
promises to achieve their claims. However, I also believe people never pay
for a company which cann't carry out. At this time, the only clear answer
seems that time will prove everything ^_~.
BR.
Brain Lai
Brian,
[18/18] from: lmecir::mbox::vol::cz at: 7-Aug-2006 6:22
Hi,
my answer is not going to be official, but I guess I can share some
informations: there are specific portability problems to more "exotic"
platforms introduced by new subsystems (take AGG as an example). The
solutions to these are not yet found, but being sought. Otherwise I
asked RT to have a look at this thread and to try to find the time
needed to discuss it.
-L
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted