Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>>>   Does it have any support for creating a (possibly encrypted) package
>>> from all the resources so that you don't have to distribute a bare version
>>> of your resources directory structure, but instead you can simply distribute
>>> this single package file with your program?
> 
>> It does have support for packaging your projects, but I don't believe it 
>> has encryption.  It's compiled into a bytecode, so it's very easy to 
>> decompile into the original sources.
> 
>   Hmm, that's not really what I asked...
> 

Sorry, you're right.  I was thinking of encrypting the sources, you were 
thinking of encrypting the data.

Anyway, as I said, it does support packaging your project.  And, to 
clarify, that includes the resources.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Anyway, as I said, it does support packaging your project.  And, to 
> clarify, that includes the resources.

  To avoid any misunderstanding: By "packaging" I don't mean "create an
installer file which you can distribute and which will install the program
in the user's computer".

  What I mean is that if it supports creating one single file which has
the data inside it, and then at runtime it reads the data directly from
that file instead of unpackaging it to the disk first (thus restoring
the original directory structure and files inside it).

  In other words, can you do so that your program consists of two files:
An executable file and a data file, and the program runs with just those
two files and doesn't create any additional files?

  Moreover, can some light encryption be applied to this data file (to
make unpackaging it slightly harder)?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> Anyway, as I said, it does support packaging your project.  And, to 
>> clarify, that includes the resources.
> 
>   To avoid any misunderstanding:

To clarify: I understand :)  That is indeed what I am trying to say that 
it does.  At least, as far as I understand it.

Hmm... I'll go try it right now to make sure it works...

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
> Warp wrote:
>> Chambers <ben### [at] pacificwebguycom> wrote:
>>> Anyway, as I said, it does support packaging your project.  And, to 
>>> clarify, that includes the resources.
>>
>>   To avoid any misunderstanding:
> 
> To clarify: I understand :)  That is indeed what I am trying to say that 
> it does.  At least, as far as I understand it.
> 
> Hmm... I'll go try it right now to make sure it works...
> 

Slight problem: The install file created repeated crashes.  I'll have to 
investigate this further, but I'm done playing with it for today.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> Darren New <dne### [at] sanrrcom> wrote:
>> nemesis wrote:
>>> *Anything* compiles extremely quickly compared to C++.  Just don't perform the
>>> same.
>> With JIT compilers and such, I'm not sure how you can be so sure. :-)
> 
> Look for the top:
>
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&binarytre
>
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
>
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1
> with memory performance taken into consideration as well, it only gets worse:
>
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1&xloc=0&binarytre
>
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
>
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1

www.tinyurl.com for next time...

Post a reply to this message

Warp escribió:
>   I have no idea about the principles used in C#, but if it's anything like
> Java, the biggest problem is not so much speed as memory usage. In Java
> I don't think there's any way around the problem that you cannot create
> a data container where each element takes as much memory as the total size
> of the members of the object, nothing more. The smaller the object is, the
> worse the memory usage overhead relative to this size.

Agreed. I hate how I can't make arrays of objects in Java. Only arrays 
of references to objects.

Post a reply to this message

Warp wrote:

>   I actually find it a bit worrying that it seems that no programming
> language introduced in the last 20 years which has got some popularity
> seems to offer any tools *whatsoever* to create memory-efficient programs
> (at least not without resorting to really ugly code which bypasses nice
> modular design).

I was about to say "Haskell" - but it's not new enough...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Warp wrote:

> >   I actually find it a bit worrying that it seems that no programming
> > language introduced in the last 20 years which has got some popularity
> > seems to offer any tools *whatsoever* to create memory-efficient programs
> > (at least not without resorting to really ugly code which bypasses nice
> > modular design).

> I was about to say "Haskell" - but it's not new enough...

  You are telling me you can create very memory-efficient programs in
haskell without resorting to ugly low-level hacks?
  That seems to be contradictory to what I remember you saying about
those ugly arrays which can be modified in-place and such.

  OTOH, I just can't stop thinking about programming from a modular point
of view. To me a program consists of "concepts". This "concept" is some
kind of module which contains some properties, ie. members (variables,
functions...) Optimally, still from a modularity point of view, these
modules will have an *abstract* public interface (ie. one which does
not expose its internal structure).

  For example, a "pixel" is a concept. On the inside it consists, for
example, of four bytes (or four 16-bit words): The red, green, blue and
alpha components. However, from a modular point of view, these are
internal implementation details, hidden from the outside. The public
interface of this module consists of abstract functions which can be
used to manipulate its contents and behavior.

  Now, this is of course just a concept. It doesn't really exist
physically yet. When you instantiate this concept you get an "object".
You can instantiate the concept many times, getting many "objects".
All these objects can be manipulated through the abstract public
interface.

  The relevant question, from an optimization point of view, is how
much memory do these objects require? If you want to create one million
of such objects, how much memory do they require?

  In C++ you can often make it so that the objects require as much
memory as the contents of the object (eg. 4 bytes) times the number
of objects (plus a few additional bytes for book-keeping). So for
example one million of such objects could require only 4 million bytes
(plus a few bytes more). And this still while keeping the abstraction
of these objects: You still don't need to know what these objects look
in the inside. The inside of the objects doesn't need to be exposed.

  In Java this is impossible. You can't make such objects to take only
4 million bytes of memory, no matter what you do. If for the "pixels"
to take that much memory is completely imperative, what you can do is
dump the nice modular abstractions and nice public interfaces completely
and resort to very ugly hacks using integer arrays. This, of course,
causes all kinds of maintenance problems. (For example, if you would
like in the future to use 8-byte pixels instead of 4-byte ones, you are
screwed.)

  I don't have the slightest idea how all this works in Haskell, though.
Being a functional language it probably doesn't even have the concept of
"module", nor the concept of "object". Can you create "concepts" (such
as "a pixel") at all? Can you instantiate these "concepts" (and, for
example, put them inside diverse types of data containers)? Does it have
the concept of "abstraction" and "public interface" which hides
implementation details?

  If I'm not completely mistaken, in Haskell you can probably define
things like "a pixel consists of these four elements". However, that
already exposes the internal structure of a "pixel". That's asking
for maintenance trouble (because then code that uses that "pixel"
concept will assume it has those four elements, which means that it
may not be possible to modify it in the future without breaking
existing code).

  Maybe there's another completely different way of doing these things
in a functional language like Haskell? I just can't get around the
modular way of thinking about programming.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   You are telling me you can create very memory-efficient programs in
> haskell without resorting to ugly low-level hacks?
>   That seems to be contradictory to what I remember you saying about
> those ugly arrays which can be modified in-place and such.

Accessing an array is no more ugly than accessing a file. (After all, 
what is a file anyway? It's a named array of bytes!) You have to use a 
monad, which makes things a bit more wordy, but that's about it.

(As I have noted before, the various array libraries are currently a 
little incomplete though...)

>   In C++ you can often make it so that the objects require as much
> memory as the contents of the object (eg. 4 bytes) times the number
> of objects (plus a few additional bytes for book-keeping). So for
> example one million of such objects could require only 4 million bytes
> (plus a few bytes more). And this still while keeping the abstraction
> of these objects: You still don't need to know what these objects look
> in the inside. The inside of the objects doesn't need to be exposed.

Short answer: Haskell can do this. But the current level of library 
support is... somewhat lacking.

[I particularly like that way that if I make an array of 4 million 
Boolean values, each one takes up exactly 1 *bit* of RAM. And yet, the 
interface is identical to any other kind of array...]

>   I don't have the slightest idea how all this works in Haskell, though.
> Being a functional language it probably doesn't even have the concept of
> "module", nor the concept of "object". Can you create "concepts" (such
> as "a pixel") at all? Can you instantiate these "concepts" (and, for
> example, put them inside diverse types of data containers)? Does it have
> the concept of "abstraction" and "public interface" which hides
> implementation details?
> 
>   If I'm not completely mistaken, in Haskell you can probably define
> things like "a pixel consists of these four elements". However, that
> already exposes the internal structure of a "pixel".

Here's the Haskell way:

Haskell has "modules". The module is the unit of abstraction in Haskell. 
When you write a module, you can define precisely what parts of it are 
visible from the outside, and which parts aren't.

Most particularly, you can make a type visible without making its 
structure visible. So you could define a Pixel type (and some functions 
for creating and manipulating Pixel values), and export the type name 
only (and the functions for working on it).

You now have a situation not disimilar to a class in Java: Only the code 
in this module knows the true implementation of Pixel. If you change 
that implementation, you'll have to change the rest of the module too, 
but any client modules will be unaffected.

So, really, it's not so different. And indeed, the standard libraries 
provide examples. There is a standard library named "Data.Set". It 
provides a type called "Set". There is a constant named "empty" which 
contains an empty set. There is a function called "insert" which takes a 
set and an item and returns a set containing that item. And so forth. 
Now, I'm *told* it's implemented with some kind of balanced tree 
algorithm, but I don't actually know. Or care. And if it changes in the 
next release of the libraries, it won't matter.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> [I particularly like that way that if I make an array of 4 million 
> Boolean values, each one takes up exactly 1 *bit* of RAM. And yet, the 
> interface is identical to any other kind of array...]

C++ STL vector template class has a specialization for 'bool' that uses 
1 bit per element too. That is, a vector<bool> takes 1 bit per element.

Post a reply to this message