Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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:g:mail 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:gma:il 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:gm:ail 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:gma:il 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:g:mail 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