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

zip file support wanted - help needed

 [1/31] from: dankelg8::cs::man::ac::uk at: 19-Mar-2001 12:17


Hi Petr, :)
> > System calls complicate things a lot. > > :-))) ;-) You don't mean it right? So that's exactly why MANY other > languages allow such features and are heavily used?
I'm just trying to argue from a different point of view, and think about the cons as well as the pros. :)
> If someone wants to use grep, let's be it. But if someone can't unpack even > stupid archive, it pretty strange ...
Ok, but each platform have different compression formats (Amiga: lha, lzx, Unix: gzip, tar, Mac: ?) So to make it user friendly for all, you'd have to cater for all these. If this happens through shell access then you loose the platfrom independence again.
> Well, as I can see - there is no power in Rebol community to make strong > enough pressure on RT to show them features discussed would be very > helpfull, if freed ... that's why I will not continue in the discussion, as > if only few ppl share the same opinion, it could be regarded being rant.
It would be interesting to hear some other opinions as well, maybe someone could put up a voting page :) Gisle

 [2/31] from: cribbsj:oakwood at: 19-Mar-2001 14:02


On Monday 19 March 2001 07:17 am, you wrote:
> Hi Petr, :) > > If someone wants to use grep, let's be it. But if someone can't unpack
<<quoted lines omitted: 4>>
> If this happens through shell access then you loose the platfrom > independence again.
No, you GAIN platforfm independence if it happens throught shell access. Why, because if I am trying to unzip a ZIP file, I just shell out and do an unzip file.zip . If it is a tar file, I shell out and do a "tar xvf file". Etc, etc. Shell access would help make the script MORE sytem/platform/programming independent, becuase you wouldn't have to worry about having a DIFFERENT version of Core that handled compression (or anything else) in different ways. In other words, RT wouldn't have to worry about making Core know how to handle zip, tar, arj, lzx, lha files, all it would have to do is make Core know how to handle letting the script have shell access. Once you do this, you open up a huge world of tools that have already been written, tested, AND made cross-platform themselves. This would free up RT so that they could do important things like finally finishing View, instead of them having to spend time reimplementing every utility (like compression) known to man.
> It would be interesting to hear some other opinions as well, maybe someone > could put up a voting page :) >
Well, I think we have been hearing other opinions. I have read four or five other replys to this thread and it is clear that others feel the same way Petr and I do. Again, RT has the right to do anything they want with Rebol. Unfortunately, programmers have the NEED to get their jobs done. I have already been forced to scrap one application I was writing for work in Rebol and re-do it in Tcl/Tk. Tcl allowed me to do the vital shell access I needed. Tk allowed me to write a front-end gui for the app. I had wanted (and actually had a prototype running) to use Core/View to do this app, but because of lack of shell access and the fact that View has not yet finished beta, I had to choose an alternative. It's too bad, because I like Rebol a lot. Jamey.

 [3/31] from: gjones05:mail:orion at: 19-Mar-2001 10:55


From: Jamey Cribbs
> Well, I think we have been hearing other opinions. I have read four or
five
> other replys to this thread and it is clear that others feel the same way > Petr and I do.
I also agree. At first I didn't think that I would miss some of the shell-access features of a scripting language, but after programming work-arounds, I suddenly was struck by how ludicrous it was to reinvent the wheel. At least in my opinion, a scripting language should have good glue-ability, which means shell access, and have the ability to be inserted in other programs as the controlling script language (which, in essence, means "open source" for all intents and purposes). I, for one, have not been opposed to paying for the /Command version. But --- I've spent too many dollars as an advanced hobbiest on prior hopeful technologies only to be "abandoned." As I have argued previously, for the language to be broadly accepted, I believe that shell access will be the minimum necessary to get other scripters to even try the language. The ability to be cross-platform compatible is a great idea in theory, and a necessity for some projects, but I prefer to have a choice in leveraging exisiting solutions through shell acess while having the option to maintain cross-platform components if and where needed (a simple switch or flag would do for me if needed).
> Again, RT has the right to do anything they want with Rebol.
Unfortunately,
> programmers have the NEED to get their jobs done. I have already been
forced
> to scrap one application I was writing for work in Rebol and re-do it in > Tcl/Tk. Tcl allowed me to do the vital shell access I needed. Tk allowed
me
> to write a front-end gui for the app. I had wanted (and actually had a > prototype running) to use Core/View to do this app, but because of lack of > shell access and the fact that View has not yet finished beta, I had to > choose an alternative. It's too bad, because I like Rebol a lot.
This has been my predicament and my course of action. I honestly prefer REBOL and /View over Tcl and Tk, but as the next /View beta expiration date rapidly approaches with so little apparent on the horizon, I refuse to let myself be left "holding the bag." I continue to follow this group cautiously optimistic that REBOL will take a turn that lets me feel confident that the future remains bright. As the problem space addressed by REBOL rapidly fills in with contenders, I have my doubts. RT needs to make some money, but they are going to need a major "buy-in" at some level to succeed, and as wonderful as the present REBOL/Core is in its free state, I'm not sure that it will be enough. Respectfully, --Scott Jones

 [4/31] from: jamesh:volition-inc at: 19-Mar-2001 11:42


Hmmm...this has degenerated quite a bit :) I think that REBOL differs from scripting languages in that it is mostly self-contained. You can do quite a bit without having any libraries or external programs AT ALL. As such, REBOL is quite the cross-platform language (note that I did not say "scripting language"). Still, it is difficult to live in a vaccuum. I have a Perl script I use for backups which makes use of a standard file compression program. I have not been able to use REBOL for the same purpose, even though it would be nicer than Perl. But there is no real problem here. If I want to access external commands, I can buy Command for, I think, $249. REBOL Technologies needs to stay in business somehow, so that's okay by me. Honestly, though, I can understand why paying that much just to be able to run external commands rubs some people the wrong way, especially in light of all the free languages that come with it standard. James

 [5/31] from: petr:krenzelok:trz:cz at: 17-Mar-2001 18:39


----- Original Message ----- From: Gisle Dankel <[dankelg8--cs--man--ac--uk]> To: <[rebol-list--rebol--com]> Sent: Friday, March 16, 2001 5:22 PM Subject: [REBOL] Re: zip file support wanted - help needed
> Petr said: > >
<<quoted lines omitted: 9>>
> > > > - as what if I don't have %some.r available? What if %some.r refers to
any
> > of your images you forgot to send me? I regard it being just completly
the
> > same kind of dependence upon "external environment" > > Hi, it's a bit crazy to argue that these are the same. > I can send you the images and the scripts, problem solved! > I can't send you the exe file if you're using a different platform. > > System calls complicate things a lot.
:-))) ;-) You don't mean it right? So that's exactly why MANY other languages allow such features and are heavily used?
> People might use grep for instance instead of parse, because they know how
If someone wants to use grep, let's be it. But if someone can't unpack even stupid archive, it pretty strange ... Well, as I can see - there is no power in Rebol community to make strong enough pressure on RT to show them features discussed would be very helpfull, if freed ... that's why I will not continue in the discussion, as if only few ppl share the same opinion, it could be regarded being rant. Well, if some of my friends asks me what tool to use for his/her daily scripting, I am not sure I can suggest Rebol here. I already lost few friends on that front already. But you should realize, that once someone startĘs to use some tool, produces many scripts e.g., spends some time using it, he/she will probably NEVER return back ... -pekr-

 [6/31] from: petr:krenzelok:trz:cz at: 20-Mar-2001 6:07


James Hague wrote:
> Hmmm...this has degenerated quite a bit :) >
yes :-)
> But there is no real problem here. If I want to access external commands, I > can buy Command for, I think, $249.
yes, without GUI support, yes ;-) I am glad here RT will produce Command + View variant in some hopefully not so distant future..... -pekr-

 [7/31] from: arolls:bigpond:au at: 20-Mar-2001 19:20


Hi, I think rebol would benefit a lot from a simple shell facility. I vote for shell access. It's a quick way of getting all sorts of stuff done. At the same time, I fear the mess we could create. :) It's the diversity versus standards argument again. Messy diversity and good, clean standards. I don't think there will ever be a winner. Anton.

 [8/31] from: dankelg8:cs:man:ac at: 16-Mar-2001 16:22


Petr said:
> I am not sure you understand my point of view? I haven't said anything > about breaking cross-platform compatibility. But - being able to execute
<<quoted lines omitted: 5>>
> of your images you forgot to send me? I regard it being just completly the > same kind of dependence upon "external environment"
Hi, it's a bit crazy to argue that these are the same. I can send you the images and the scripts, problem solved! I can't send you the exe file if you're using a different platform. System calls complicate things a lot. People might use grep for instance instead of parse, because they know how to use grep and haven't bothered to look at the docs for parse. Gisle

 [9/31] from: chris:starforge at: 16-Mar-2001 17:42


#16-Mar-01# Message from *Gisle Dankel*: Hi Gisle,
> People might use grep for instance instead of parse, because they know how > to use grep and haven't bothered to look at the docs for parse.
In that case they are being lazy and they deserve the complaints they will inevitably get. Yes, that is only one example. Yes, a system function would be abusable. But do you actually have *any* idea how important a system function is to real cgi programmers? There are things that you simply CAN NOT DO with REBOL because it doesn't have the facility to invoke other programs. Which is worse: to allow lazy programmers to write bad code (something which happens anyway) while making REBOL a viable language for real cgi work, or to put off anyone who can be bothered to read a python, perl or C book because they have to go through an assault course just to run another program in REBOL? Think about that HARD, especially try to look at it from the viewpoint of a company which needs to gain widespread acceptance. Put this another way: are you forced to use scripts written by lazy programmers? If not, why get yourself in a knot that they are making work for themselves? Many of us who are pushing REBOL beyond its limits need some way to get it to talk to the real world outside a web browser or TCP protocol - a system function is the only way this can be done. Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- Do Roman paramedics refer to IV's as "4's"?

 [10/31] from: chris:starforge at: 14-Mar-2001 20:26


#14-Mar-01# Message from *Gisle Dankel*: Hi Gisle,
> I really like the fact that there's no shell access in Rebol/core. > It means I can take just about any script and use it on any computer, > which I do, all the time.
In an ideal world, or if REBOL supported all the facilities you would ever need for real life deployment, this would be great. But this is not an ideal world and REBOL does not support all the things that are needed. In my case, my hoster has disabled the SMTP deamon for security purposes, they can safely assume that people who want to write cgi scripts that generate emails can simply invoke sendmail /because every other language used for cgi can/. And, from asking around, this is a fairly common security precaution, not just a paranoid sys admin. And there are other situations where running external programs is helpful, even necessary. The feature may be abused to add "eye candy", but in my experience a lot of serious cgi coders can not take a language seriously unless it can at least launch other programs. Many of the coders I know stated the opinion that they thought REBOL overly restrictive , one even called it useless, after I discussed this problem with them. The fact that it is possible to do workarounds like I have is a point in REBOL's favour, but the fact that it is needed at all is a severe impediment to getting coders who use perl, python, c and the rest to convert. And unless RT want REBOL to end up as a niche company networking lanugange they are going to have to face this problem sooner or later IMO. A system or exec function may not be the easiest or nicest thing to include, but it is vital to any serious cgi scripting language.. Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- Blood is thicker than water, and much tastier.

 [11/31] from: gjones05:mail:orion at: 15-Mar-2001 13:31


From: "Chris"
<snip> > The fact that it is possible to do workarounds like I have is a point in > REBOL's favour, but the fact that it is needed at all is a severe
impediment
> to getting coders who use perl, python, c and the rest to convert. And > unless RT want REBOL to end up as a niche company networking lanugange > they are going to have to face this problem sooner or later IMO. <snip>
Well stated! --Scott Jones

 [12/31] from: joel:neely:fedex at: 15-Mar-2001 15:09


Hello, Petr, (and world!)... Petr Krenzelok wrote:
> I know what multiplatform issue means. I am sorry but sometimes all > that be-multiplatform-or-die voices sounds a little bit > "masochistic" to me :-) >
Perhaps, but the demands of a typical multiplatform each-box-does- -things-differently seem more than a little bit sadistic to me ;-)
> Isn't purpose of language to SOLVE various situations in first > place? How often do MOST ppl in reality need their solution to work > on more than one platform? On more than two platforms? etc.? >
I can only speak for myself, but I LIVE in a multiplatform world ... Solaris HP-UX Linux w95 w2000 MacOS ... and consider cross-platform compatibility to be a survival issue rather than a luxury, for at least the following reasons: 1) I have frequently needed to use a script or reusable object on many of the above platforms to get actual work done. 2) Even when not deploying the final code to multiple platforms for "real" use, I have found it convenient (if not necessary) to be able to do development in one environment (e.g., my laptop, home box, etc.) of code that I will actually use "for real" in another. 3) I often have needed to "do nuclear physics" on REBOL -- perform one or more semi-obscure experiments in an attempt to deduce the way that some feature of the language works, or to confirm my mental model of how it works -- in order to use REBOL for some specific task. It's been VERY useful to be able to do such things with whichever platform is at hand. 4) Even when specific finished pieces of code haven't needed to move from one platform to another, the experience I've gained writing something on one platform has enabled me to re-use the same ideas and skills on all REBOL-enabled platforms -- without even having to think about that fact! 5) There is substantial productivity gain from the fact that REBOL provides a clean conceptual basis for doing many things that require mass quantities of picky and variable details with other languages on various platforms. Consider how much code it would take to say foo: read http://www.bletch.com/ using language X on platform Y. This gain is addictive; having once tasted its nectar, I am loathe to return again to the fetid swamp of proprietary irrelevantia.
> We should probably find some balance here. Many ppl here expressed > need for link to external environments here already. We probably > lost some ppl already too because of that fact. >
With respect to point (5) above, it is the very high standard that REBOL sets for clarity and expressivity that is the origin of those (assuredly few) places where I find myself frustrated with REBOL. For example, it is beautiful to be able to say any of: baz-from-web: read http://www.xxx.com/ baz-from-ftp: read ftp://ftp.xxx.com/ baz-from-disk: read %/path/to/file.data trusting READ to handle the trivia implicit in those similar-in-idea but very-different-in-implementation-detail access methods. Coming from that "high", it is a very deep "low" indeed to discover that I am left so much to my own devices in handling CGI input -- having to concern myself with very different aspects of the lightly-documented SYSTEM object depending only on the length of my input! It is of little help to have the "GET" vs. "POST" distinction managed for me, only to trip over some magic buffer size limit. In a related example, there is a wealth of relevant information for a CGI program that is available via the system environment. I found it truly baffling not to have all of these same parameters offered via a single object or associative data store, but rather split up into different "places". I'm sure that this is not quite what you meant in your reference to external environments , but it is an example of a concept that is widely available in many platforms and languages, and which has some fairly obvious incarnations in REBOL (e.g., object fields or assoc. data store) and yet was either obscured or taken completely away from the programmer. I don't want to sound as if I am condemning REBOL or RT here, but rather I am suggesting that the quest for perfection admits of no balance points. The more beautiful and elegant the majority of the language is, the more glaring the small imperfections are by contrast. Once we start down the road of freeing the programmer from platform minutia, it is hard to find an acceptable off ramp! Joel "I think I just used two weeks quota of REBOL time" Neely

 [13/31] from: petr:krenzelok:trz:cz at: 16-Mar-2001 7:10


Joel Neely wrote:
> Hello, Petr, (and world!)... > Petr Krenzelok wrote:
<<quoted lines omitted: 5>>
> Perhaps, but the demands of a typical multiplatform each-box-does- > -things-differently seem more than a little bit sadistic to me ;-)
yes, it does, but adding /shell support or even /library one works completly the same way thru all the platforms ;-)
> > Isn't purpose of language to SOLVE various situations in first > > place? How often do MOST ppl in reality need their solution to work
<<quoted lines omitted: 9>>
> ... and consider cross-platform compatibility to be a survival issue > rather than a luxury, for at least the following reasons:
OK, I can understand it - I have nothing against cross-platform compatibility of language itself, but it's not in opposite what did I say in previous email ... I am not sure you understand my point of view? I haven't said anything about breaking cross-platform compatibility. But - being able to execute external app by: call "some.exe" sounds pretty the same to me as do %some.r - as what if I don't have %some.r available? What if %some.r refers to any of your images you forgot to send me? I regard it being just completly the same kind of dependence upon "external environment" Let's stand the facts, please: - including /shell or /library into /Core DOESN'T prevent you from performing any of your test, which requires strong compatibility - current state LIMITS Rebol from certain area of usage. What if some app provides you output in .zip format? :-) You are dead using /Core, while what's more - you could find many usefull utils (e.g. aforementioned .zip) for whole bunch of platforms, including those you are using personally :-) - current state CAUSED some ppl left us. (e.g. /Apache situation and some opinions stating text databases are suitable for most cases ... I am not arguing here, but 3 of my friends refused to even bother to look into /Apache module beta once I told them there's no link to SQLs). I would like to suggest to NOT depreciate such factor. Bad reference is very dangerous. One person can affect many ppl's opinion. - my personal POV is - it's not cross-platform compatibility, which holds RT back from inclusion of /shell or /library into /Core, but licencing/money related issue. - My opinion is - language is stable enough to allow inclusion of /shell or even /library into core language .... What other things current state of things shows?: - there were many requests cor features like sound, ability to do this or that ... that shows something .... - what about cross-platform solutions like: http://www.libsdl.org/ - multimedia libraries ... you can find there Python, Perl ... for free. But you will NOT find Rebol there. There is many ppl who would like to use Rebol just for joy - bobbyists. The will not/can't buy/afford to buy 249 or even 4xx USD /Command just to call external library or launch externall app ... I call it .... reality check ... ;-) Cheers, -pekr-

 [14/31] from: sharriff:aina:med-iq at: 16-Mar-2001 6:50


PEKR wrote:
>- what about cross-platform solutions like: http://www.libsdl.org/ - >multimedia libraries ... you can find there Python, Perl ... for
Greeeaat! I have been looking for something like this for Python for weeks, Thanks for the link Pekr! Best regards Sharriff Aina

 [15/31] from: petr:krenzelok:trz:cz at: 14-Mar-2001 16:08


Paul Tretter wrote:
> I think that is unimportant right now given that we have compress and > already distributed ".rip files. Seems good enough. Anyone else?...
I discussed it with Carl some time ago ... and I can't agree here :-) According to him, most US users use default Windows Explorer. But in my opinion, that piece of code is pretty crap as goes for file manager. Merely EACH GOOD file manager knows how to treat .zip or other archives - as ordinary directory. - you just press enter to enter them, you select files wanted - can delete them, edit them, copy them out of the archive. .RIP is fine, but I (and probably others too) work almost constantly with file manager (Windows Commander in particular). It's imo needed. IF Rebol/Core would at least support /Shell component, you could always call externall app to unpack files for you, but with current state of things, we are pretty dead once dealing with existing archives .... even RT uses .zip for their product distribution - not .rip ;-) Just my opinion ... Anyone else? -pekr-

 [16/31] from: cribbsj:oakwood at: 14-Mar-2001 11:14


Couldn't agree with you more about shell access. I believe it was yesterday that someone posted a script he had written that allowed him to send an email via sendmail. It was a great piece of programming, but I find it humorous that he actually had to jump through that many hoops just to do something that would be very easy if core included shell access. I've heard the reasons RT gives for not including shell access in core...and they just don't wash with me. But, it's there product. Jamey. On Wednesday 14 March 2001 10:08 am, you wrote:

 [17/31] from: chris:starforge at: 14-Mar-2001 19:12


#14-Mar-01# Message from *Jamey Cribbs*: Hi Jamey,
> but I find it humorous that he actually had to jump through > that many hoops just to do something that would be very easy if core > included shell access.
That is the one major problem I have with /core - I can do more or less everything else I need with it but directly invoking external programs.. IMO the fact that this can not be done is a serious dent in the viability of REBOL as a serious scripting language. Perl does it, Python can do it (AFAIK), C, C++ and the like can do it. And these are the languages REBOL has to go head to head with it it is to become a widespread scripting language. While it is possible to write cgi scripts in other languages to do the job and then call that script from REBOL, as I do with the emailer script, many people would find that hightly inconvenient.
> I've heard the reasons RT gives for not including shell access in > core...and they just don't wash with me. But, it's there product.
I've never hear /why/ the feature isn't there.. but I can hazard a guess as to why.. Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- You couldn't even prove the White House staff sane beyond a reasonable doubt. -- Ed Meese, on the Hinckley verdict

 [18/31] from: ptretter:norcom2000 at: 14-Mar-2001 13:32


Would be nice if RT could give us just enough information to allow us to create OS specific extensions that would launch external processes. Paul Tretter

 [19/31] from: dankelg8:cs:man:ac at: 14-Mar-2001 20:01


Hi Jamey, I really like the fact that there's no shell access in Rebol/core. It means I can take just about any script and use it on any computer, which I do, all the time. I do rebol programming on three different platforms depending on where I am at the moment. If shell access was available I have a feeling that people would use it more than necessary to add 'cool' features etc by hooking up to resources which doesn't exist (or works differently) on some platforms. It would be a lot of extra work to get these programs to work on all platforms. A program such as a file manager should really work on all platforms, don't you think? Working with REBOL is a breath of fresh air compared to Working with Java and other languages wich claims to be platform independent. REBOL really does work flawlessly across platforms. With other languages there are all sorts of issues. The way it is now, with REBOL/Command available for purchase, suits me very well, and I think most newcomers with little experience in programming will feel the same way. Gisle On Wed, 14 Mar 2001, Jamey Cribbs wrote:

 [20/31] from: petr:krenzelok:trz:cz at: 14-Mar-2001 23:04


----- Original Message ----- From: Gisle Dankel <[dankelg8--cs--man--ac--uk]> To: <[rebol-list--rebol--com]> Sent: Wednesday, March 14, 2001 9:01 PM Subject: [REBOL] Re: zip file support wanted - help needed
> Hi Jamey, > I really like the fact that there's no shell access in Rebol/core.
<<quoted lines omitted: 16>>
> very well, and I think most newcomers with little experience in > programming will feel the same way.
Each coin has two sides, of course. Well, what about following:? Lack of /shell and /library components in /Core language limits general language acceptance pretty well .... I know what multiplatform issue means. I am sorry but sometimes all that be-multiplatform-or-die voices sounds a little bit "masochistic" to me :-) Isn't purpose of language to SOLVE various situations in first place? How often do MOST ppl in reality need their solution to work on more than one platform? On more than two platforms? etc.? We should probably find some balance here. Many ppl here expressed need for link to external environments here already. We probably lost some ppl already too because of that fact. What about even this?: I will produce some script, which is supposed to call some other script, or load image .... but I will forget to send you such image. My script works on my platform, but does not on another one. It IS dependant on my environment, using current /Core. In opposite - what about this?: I want to call external archiver, pkzip for e.g. Have you realised, that you can find some freeware utils for almost any platform you can imagine? And if you don't have gzip with your platform installed? So what? One script will not work. But if you want, you CAN code the same way as today - being truly multiplatform .... So you still prefer the way to be "dead" in certain areas? Or you want to suggest me to buy 2xx or 4xx USD /Command, just to execute external utility? I think /Express is the answer for RT to make money. It's a product, which adds value to Rebol technology, while /Core, /Shell and /Library should be regarded technologies imo. ... being with Rebol from its beginning, I think it completly deserves much more acceptance. And that's the reason I would let ppl to use it in whatever environment they can imagine. At least in non-commercial environments .... I can't help myself, sorry :-) -pekr-

 [21/31] from: rgombert:essentiel at: 15-Mar-2001 7:41


I have to agree with Petr... at least we nead ability to launch external application or documents (with their default "viewer"). Adding shell and library to /Core would be great, but in fact we have to consider that /Core and /Command are not realeased for the same number of OS, mainly because of the library and DB functionality i gess. I can understand that... but would it be so much work to add only the shell support to Core ? I think it's a verry important feature requiered by most users, and it is provided by other scripting languages. Rebol is a realy great language, i would like to see its bright success... maybe i'm wrong, but i feel that discading shell acces is not a good point to achive such a success. Renaud

 [22/31] from: robert:muench:robertmuench at: 15-Mar-2001 8:22


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On
<<quoted lines omitted: 4>>
> I've heard the reasons RT gives for not including shell access in > core...and they just don't wash with me. But, it's there product.
Hi, I'm not that happy with this too. I can understand the RT needs to earn some money and I think that the database support is worth it. How about this: RT includes a shell access feature, which just let you start an external program (no DLLs etc.). IMO this would make a lot of sense and most of us would be happy, further it doesn't strip the /Command feature set to pay for to much. I would pay for /Command because of DLL and database support, not only shell access. Robert

 [23/31] from: robbo1mark:aol at: 15-Mar-2001 3:13


I would usually say something here, but saying it upset's some people so I won't say it this time! Mark Dickson http://groups.yahoo.com/group/OSCAR-PROJECT

 [24/31] from: petr:krenzelok:trz:cz at: 15-Mar-2001 11:05


[Robbo1Mark--aol--com] wrote:
> I would usually say something here, but saying it upset's some people so I > won't say it this time!
:-))) It would be sufficient to say: "I agree with Petr", wouldn't it? :-) Cheers, -pekr-

 [25/31] from: robbo1mark:aol at: 15-Mar-2001 7:14


okay if you insist! I very strongly agree! Mark In a message dated Thu, 15 Mar 2001 5:25:04 AM Eastern Standard Time, Petr Krenzelok <[Petr--Krenzelok--trz--cz]> writes: << [Robbo1Mark--aol--com] wrote:
> I would usually say something here, but saying it upset's some people so I > won't say it this time!
:-))) It would be sufficient to say: "I agree with Petr", wouldn't it? :-) Cheers, -pekr-

 [26/31] from: petr:krenzelok:trz:cz at: 14-Mar-2001 8:24


Hi, today I talked to Carl at Express conference. We talked about possibility of adding .zip support to Rebol. Few ppl requested the feature some time ago, and I can personally find it usefull. WinAmp for e.g. uses .zip files for skins too, it even doesn't unpack them on hd. I surely don't know Rebol internals, but maybe it could work as a scheme? e.g.: write %rebol.exe read zip:///c/rebol/download/core031.zip/rebol.exe Rebol currently has some kind of compression/decompression available. Carl agreed to support requested feature, but RT lacks enough manpower to handle all tasks they need to do. So - is here anyone who knows C well, and would like to code it for RT? Or at least - are there any sources available to study, or even complete open source solutions (of course, with licence allowing RT to add it into Rebol)? Thanks, -pekr-

 [27/31] from: jkinraid:clear at: 14-Mar-2001 21:12


Hi Pekr,
> today I talked to Carl at Express conference. We talked about > possibility of adding .zip support to Rebol. Few ppl requested the > feature some time ago, and I can personally find it usefull. WinAmp for > e.g. uses .zip files for skins too, it even doesn't unpack them on hd. I > surely don't know Rebol internals, but maybe it could work as a scheme? > e.g.:
Doesn't WinAmp unpack them to your Windows temp dir?
> write %rebol.exe read zip:///c/rebol/download/core031.zip/rebol.exe > Rebol currently has some kind of compression/decompression available.
<<quoted lines omitted: 3>>
> sources available to study, or even complete open source solutions (of > course, with licence allowing RT to add it into Rebol)?
http://www.info-zip.org/pub/infozip/ Uses a BSD based license. Julian Kinraid

 [28/31] from: robert:muench:robertmuench at: 14-Mar-2001 10:22


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On
<<quoted lines omitted: 5>>
> possibility of adding .zip support to Rebol. Few ppl requested the > feature some time ago, and I can personally find it usefull.
Hi Petr, yes I think it's a good idea.
> write %rebol.exe read zip:///c/rebol/download/core031.zip/rebol.exe
Looks OK to me.
> Rebol currently has some kind of compression/decompression available.
Should this be changed or a new one added?
> Carl agreed to support requested feature, but RT lacks enough manpower > to handle all tasks they need to do. So - is here anyone who knows C > well, and would like to code it for RT?
Well, this sounds very good. I might help for this part. How to proceed?
> Or at least - are there any > sources available to study, or even complete open source solutions (of > course, with licence allowing RT to add it into Rebol)?
Didn't checked the license but there is a ZIP compressor within the PNG graphics format package. I think it's ZLIB. Don't know if its suitable but worth a look anyway. Robert M. Muench

 [29/31] from: petr:krenzelok:trz:cz at: 14-Mar-2001 10:54


Robert M. Muench wrote:
> > -----Original Message----- > > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On
<<quoted lines omitted: 10>>
> > Rebol currently has some kind of compression/decompression available. > Should this be changed or a new one added?
Carl expressed opinion, that they internally use compression/decompression already and would not like to add second one. I am not sure we can proceed without knowing how it works inside Rebol. Perhaps someone from RT could clarify or set some guidelines for us to proceed?
> > Carl agreed to support requested feature, but RT lacks enough manpower > > to handle all tasks they need to do. So - is here anyone who knows C > > well, and would like to code it for RT? > > Well, this sounds very good. I might help for this part. How to proceed? >
as stated above. If you already know how to help the situation, or you have anything concrete in mind, please express it here ....
> > Or at least - are there any > > sources available to study, or even complete open source solutions (of > > course, with licence allowing RT to add it into Rebol)? > > Didn't checked the license but there is a ZIP compressor within the PNG > graphics format package. I think it's ZLIB. Don't know if its suitable but > worth a look anyway. Robert M. Muench >
yes: http://www.info-zip.org/pub/infozip/zlib/ Cheers, -pekr-

 [30/31] from: robert:muench:robertmuench at: 14-Mar-2001 13:40


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On
<<quoted lines omitted: 4>>
> Carl expressed opinion, that they internally use compression/decompression > already and would not like to add second one.
Hi, I think this makes sense.
> I am not sure we can proceed > without knowing how it works inside Rebol. Perhaps someone from RT could > clarify or set some guidelines for us to proceed?
I would suggest that the one-who-implements the ZIP stuff just write it standalone (clean and lean) and that RT will include it than into their source-tree.
> as stated above. If you already know how to help the situation, or you
have
> anything concrete in mind, please express it here ....
I didn't dig to deep yet but here are some more links of interest: http://www.ddj.com/topics/compression/ http://www.dogma.net/DataCompression/ http://www.dogma.net/markn/ This is the homepage of Mark Nelson, I have a old piece of code for a ZIPer, which is 8054 bytes long. Quite cool, might be a good starting point. Robert

 [31/31] from: ptretter:norcom2000 at: 14-Mar-2001 8:32


I think that is unimportant right now given that we have compress and already distributed ".rip files. Seems good enough. Anyone else?... Paul Tretter

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted