On Thursday, 10 April 2014 at 15:19:45 UTC, Iain Buclaw wrote:
> On 10 April 2014 01:31, Harpo <roederharpo@gmail.com> wrote:
>> Hello. Here is a programming language that is coded in D. The documentation
>> is included in the file. It is ment to be used as a general purpose
>> scripting language. Its name is HarpoScript. It has enough features for
>> general purpose work at the moment, however its not exactly efficient. If
>> you are interested check it out! Note it is only compiled for 64bit Linux.
>>
>> Link: http://www.mediafire.com/download/cjae0pnxmjpl7au/HarpoScriptR2.tar.gz
>
> I recommend putting the source somewhere, such as github. :)

I was going to suggest same but I think there's no source code available. At least, I can't find it.

On 10.04.2014 18:47, Harpo wrote:
> What do you mean? There are a couple demo programs. I also
> include some individual doc that explains what the different
> features are. The project may be creative commons at some point.
> Running a program is just running the executable with the program
> name as the parameter.

I mean without source or library/API it seems no way to embed it in host application, which is the point of any scripting language.

On Thursday, 10 April 2014 at 00:31:34 UTC, Harpo wrote:
> Hello. Here is a programming language that is coded in D. The documentation is included in the file. It is ment to be used as a general purpose scripting language. Its name is HarpoScript. It has enough features for general purpose work at the moment, however its not exactly efficient. If you are interested check it out! Note it is only compiled for 64bit Linux.
>
> Link: http://www.mediafire.com/download/cjae0pnxmjpl7au/HarpoScriptR2.tar.gz

You'll get a lot more interest if you put this somewhere a more public and reliable than a tarball on mediafire. Put the source in a github/bitbucket repo perhaps?

As it is, I'm wary of touching random mediafire links to binaries on a mailing list.

On 4/10/2014 11:23 AM, Chris wrote:
>
> Also, after
> extracting the archive the folder is called "release". One would expect
> HarpoScript/release/. Little annoyances put people off.

Creating a subdirectory with the same name as the archive is the job of an extracting tool. Archives with a redundant internal directory are annoying.

On Thu, Apr 10, 2014 at 18:42:14 -0400, Nick Sabalausky wrote:
> Creating a subdirectory with the same name as the archive is the job of an extracting tool. Archives with a redundant internal directory are annoying.

Maybe in a perfect world. We do not live in such a place (especially since tools don't flag 'tarbombs' as anything different). Either way, get a flag added to tar for such a thing and maybe folks wouldn't care so much about tarbombs anymore.

--Ben

On 11/04/14 00:17, John Colvin wrote:

> You'll get a lot more interest if you put this somewhere a more public
> and reliable than a tarball on mediafire. Put the source in a
> github/bitbucket repo perhaps?
>
> As it is, I'm wary of touching random mediafire links to binaries on a
> mailing list.

Yeah, I haven't bothered to look at this because I can't view the source code in a web browser.

-- 
/Jacob Carlborg

On 4/11/2014 1:41 AM, Ben Boeckel wrote:
> On Thu, Apr 10, 2014 at 18:42:14 -0400, Nick Sabalausky wrote:
>> Creating a subdirectory with the same name as the archive is the job
>> of an extracting tool. Archives with a redundant internal directory
>> are annoying.
>
> Maybe in a perfect world. We do not live in such a place (especially
> since tools don't flag 'tarbombs' as anything different). Either way,
> get a flag added to tar for such a thing and maybe folks wouldn't care
> so much about tarbombs anymore.
>

It's just that...It never made any sense to me whatsoever that an archive extractor should *EVER* fail to implicitly create a same-named directory for all the archive's contents - except when the user *specifically* says not to.

The convention of expecting *people* (or even archivers for that matter) to always stick a redundant dummy directory into their archives (and, naturally, to keep its name reasonably in sync with the archive's filename - which rules out automatically handling the matter on the archiver's end) is guaranteed to be error-prone. And yet, AFAICS, it exists *purely* as a workaround for extractors failing to, by default, do the *only* thing that really makes sense as a default in the first place.

Illustrating this, here's how I have my system working: I only ever use the "extract to a new same-named directory" feature of an extractor (in my case, that's generally WinRAR's or 7-Zip's Explorer shell integration). The only exception is the *rare* special-case where an archive is intended to be extracted overtop a specific existing directory - and even that's a questionable practice anyway. Whenever possible, I avoid extractors that don't have this "to a new same-named directory" feature.

What that means is I'm guaranteed to *never* have archives clobber, or spew files into, the wrong directory. And yet I get that *without* relying on a human convention that will *never* reliably reach a 100% adoption rate anyway.

The only downside I face is that extracting archives from those trying to workaround ill-behaved extractors results in an extra superfluous directory. An annoyance (well, a pet-peeve TBH), but clearly not anywhere near as bad.

I just don't see how it could *possibly* make any sense to NOT do it this way.

Well, that's my rant about it, anyway. ;)

On Fri, Apr 11, 2014 at 9:26 AM, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> The only downside I face is that extracting archives from those trying to workaround ill-behaved extractors results in an extra superfluous directory. An annoyance (well, a pet-peeve TBH), but clearly not anywhere near as bad.
>
> I just don't see how it could *possibly* make any sense to NOT do it this way.
>
> Well, that's my rant about it, anyway. ;)
>
>
:) on Ubuntu the default extractor always creates a new directory and if it finds a single directory inside that new directory after extraction is moves that directory out of the new directory and deletes the now empty new directory.

On 4/11/2014 3:39 AM, Rory McGuire wrote:
>
> :) on Ubuntu the default extractor always creates a new directory and if it
> finds a single directory inside that new directory after extraction is
> moves that directory out of the new directory and deletes the now empty new
> directory.
>

Personally, I'd prefer if it was the single lone directory *inside* the archive that was removed since their names aren't always the same as the archive, which is messy and just leads to pointless confusion. But yea, sounds like they definitely have the right idea.

On Thursday, 10 April 2014 at 22:42:19 UTC, Nick Sabalausky wrote:
> On 4/10/2014 11:23 AM, Chris wrote:
>>
>> Also, after
>> extracting the archive the folder is called "release". One would expect
>> HarpoScript/release/. Little annoyances put people off.
>
> Creating a subdirectory with the same name as the archive is the job of an extracting tool. Archives with a redundant internal directory are annoying.

I simply expect MyArchive.tar.gz > MyArchive/

and not

MyArchive.tar.gz > release

Simply annoying when you cannot find the folder with the content, because it has a completely different name.