HSL and HSL-pico...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

HSL and HSL-pico...

Dion Amago
I have modified versions of HSL and HSL-pico that I would like to distribute with the haxe game engine I've been working on.  I would like to distribute them directly in with the game library src, in
other words, I don't want to have a separate lib folder that the user of the game library has to worry about.

Practically speaking, I want the use to have this in their build.hxml file:
-lib hydrax
or
-src path/to/hydrax

and *not*:

-src path/to/hydrax/src
-src path/to/hydrax/lib/hsl
-src path/to/hydrax/lib/hsl-pico

Since hsl uses SVN and my project uses git, normally this would be no problem, I would keep the local .svn folders in my local copy, and I could keep hsl updated as needed easily.

However, since hsl splits up the hsl and hsl-pico parts, this cannot be done, since there are overlapping source folders.

So what is the reason for splitting up the source folders?  Having used hsl for a while now, I have to admit that the split was confusing (especially the name "pico", meaning smaller I guess, but what
does smaller mean here?  Simpler?  Lighter?), and doesn't help in any practical sense, and just means more to worry about (did I forget to include -lib hsl-pico *and* lib hsl).

If the reason is for clarity, then I don't think it adds anything more than well ordered source folders.  The wiki is good enough to get you started.
If the reason is for space issues, that also doesn't make sense, since the whole library is tiny, and anyway code is a tiny fraction of any project, with any image or blob easily being much bigger.

So I propose to merge them for the sake of simplicity.  Or maybe there's a good reason for the split that I just don't see.

Dion

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: HSL and HSL-pico...

Pimm Hogeling
Hey Dion,

Thanks for the feedback.

First things first: your message kind of suggests that the split requires some effort on the developers part. But generally, you never have to worry about the split. You can specify hsl-1 as a lib, hsl-pico-1 will automatically be included under the hood. The haXe compiler is that smart. However, in your case, I understand how the split is problematic.

I'll explain why it was decided that the library would be split up into two parts. As HSL was growing, and stuff like translations of native event systems got added, some haXe developers argued that they would never use all those extras and it would just be in their way. They mentioned that they would prefer a simpler library. As you know, HSL was designed to be usable for all haXe developers in both small and big projects, so something had to be done to satisfy those developers.

However, this might not be relevant anymore. I'd like to hear some more feedback from other users.

Personally, I don't care whether the library is split or not: I never use HSL-pico as a standalone library; nor do I ever have (technical) problems with them being split.

I hope this answers your question, and I hope to get some feedback on this from the others.

On 22 November 2010 02:33, Dion Amago <[hidden email]> wrote:
I have modified versions of HSL and HSL-pico that I would like to distribute with the haxe game engine I've been working on.  I would like to distribute them directly in with the game library src, in
other words, I don't want to have a separate lib folder that the user of the game library has to worry about.

Practically speaking, I want the use to have this in their build.hxml file:
-lib hydrax
or
-src path/to/hydrax

and *not*:

-src path/to/hydrax/src
-src path/to/hydrax/lib/hsl
-src path/to/hydrax/lib/hsl-pico

Since hsl uses SVN and my project uses git, normally this would be no problem, I would keep the local .svn folders in my local copy, and I could keep hsl updated as needed easily.

However, since hsl splits up the hsl and hsl-pico parts, this cannot be done, since there are overlapping source folders.

So what is the reason for splitting up the source folders?  Having used hsl for a while now, I have to admit that the split was confusing (especially the name "pico", meaning smaller I guess, but what
does smaller mean here?  Simpler?  Lighter?), and doesn't help in any practical sense, and just means more to worry about (did I forget to include -lib hsl-pico *and* lib hsl).

If the reason is for clarity, then I don't think it adds anything more than well ordered source folders.  The wiki is good enough to get you started.
If the reason is for space issues, that also doesn't make sense, since the whole library is tiny, and anyway code is a tiny fraction of any project, with any image or blob easily being much bigger.

So I propose to merge them for the sake of simplicity.  Or maybe there's a good reason for the split that I just don't see.

Dion

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: HSL and HSL-pico...

Dion Amago
I don't mean to be disrespectful to other developer's needs, but for
almost all external libraries out there, usually you only use a small
part of a given library.  It really only makes sense to split a library
if the two parts do something substantially different from one another,
not when one is simply a subset of the other.  I don't know enough about
the other compilers, but for flash and javascript, whatever code you
don't import is not included in the compiled form, so the simplicity is
only from a development point of view, not a "this is making my
application fatter" problem.  This usability issue of code "being in the
way" arises from the existence of a few extra source subfolders.  Do
those few extra folders really put a brake on development?

Dion

Pimm Hogeling wrote:
> I'll explain why it was decided that the library would be split up
> into two parts. As HSL was growing, and stuff like translations of
> native event systems got added, some haXe developers argued that they
> would never use all those extras and it would just be in their way.
> They mentioned that they would prefer a simpler library. As you know,
> HSL was designed to be usable for all haXe developers in both small
> and big projects, so something had to be done to satisfy those developers.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: HSL and HSL-pico...

Pimm Hogeling
I agree with you, Dion: even if I wanted to use just the pico part of HSL, the rest wouldn't be in the way.

On 22 November 2010 18:37, dionjw <[hidden email]> wrote:
I don't mean to be disrespectful to other developer's needs, but for almost all external libraries out there, usually you only use a small part of a given library.  It really only makes sense to split a library if the two parts do something substantially different from one another, not when one is simply a subset of the other.  I don't know enough about the other compilers, but for flash and javascript, whatever code you don't import is not included in the compiled form, so the simplicity is only from a development point of view, not a "this is making my application fatter" problem.  This usability issue of code "being in the way" arises from the existence of a few extra source subfolders.  Do those few extra folders really put a brake on development?

Dion


Pimm Hogeling wrote:
I'll explain why it was decided that the library would be split up into two parts. As HSL was growing, and stuff like translations of native event systems got added, some haXe developers argued that they would never use all those extras and it would just be in their way. They mentioned that they would prefer a simpler library. As you know, HSL was designed to be usable for all haXe developers in both small and big projects, so something had to be done to satisfy those developers.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: HSL and HSL-pico...

Cauê W.
Well, I actually enjoy separating the lib in two parts, like a core and extensions. And also since haxelib knows dependencies directly, there is no problem in using directly hsl-1, while you can depend only on the hsl core, hsl-pico.

2010/11/26 Pimm Hogeling <[hidden email]>
I agree with you, Dion: even if I wanted to use just the pico part of HSL, the rest wouldn't be in the way.


On 22 November 2010 18:37, dionjw <[hidden email]> wrote:
I don't mean to be disrespectful to other developer's needs, but for almost all external libraries out there, usually you only use a small part of a given library.  It really only makes sense to split a library if the two parts do something substantially different from one another, not when one is simply a subset of the other.  I don't know enough about the other compilers, but for flash and javascript, whatever code you don't import is not included in the compiled form, so the simplicity is only from a development point of view, not a "this is making my application fatter" problem.  This usability issue of code "being in the way" arises from the existence of a few extra source subfolders.  Do those few extra folders really put a brake on development?

Dion


Pimm Hogeling wrote:
I'll explain why it was decided that the library would be split up into two parts. As HSL was growing, and stuff like translations of native event systems got added, some haXe developers argued that they would never use all those extras and it would just be in their way. They mentioned that they would prefer a simpler library. As you know, HSL was designed to be usable for all haXe developers in both small and big projects, so something had to be done to satisfy those developers.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: HSL and HSL-pico...

Pimm Hogeling
Hey Cauê, thanks for the feedback.

The follow-up question would be: do you actually depend on HSL-pico only in at least some of your projects, or do you just like the idea of being able to?

On 26 November 2010 12:02, Cauê Waneck <[hidden email]> wrote:
Well, I actually enjoy separating the lib in two parts, like a core and extensions. And also since haxelib knows dependencies directly, there is no problem in using directly hsl-1, while you can depend only on the hsl core, hsl-pico.

2010/11/26 Pimm Hogeling <[hidden email]>
I agree with you, Dion: even if I wanted to use just the pico part of HSL, the rest wouldn't be in the way.


On 22 November 2010 18:37, dionjw <[hidden email]> wrote:
I don't mean to be disrespectful to other developer's needs, but for almost all external libraries out there, usually you only use a small part of a given library.  It really only makes sense to split a library if the two parts do something substantially different from one another, not when one is simply a subset of the other.  I don't know enough about the other compilers, but for flash and javascript, whatever code you don't import is not included in the compiled form, so the simplicity is only from a development point of view, not a "this is making my application fatter" problem.  This usability issue of code "being in the way" arises from the existence of a few extra source subfolders.  Do those few extra folders really put a brake on development?

Dion


Pimm Hogeling wrote:
I'll explain why it was decided that the library would be split up into two parts. As HSL was growing, and stuff like translations of native event systems got added, some haXe developers argued that they would never use all those extras and it would just be in their way. They mentioned that they would prefer a simpler library. As you know, HSL was designed to be usable for all haXe developers in both small and big projects, so something had to be done to satisfy those developers.

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org