July 18, 2012
On Wed, 18 Jul 2012 11:12:22 +0200
Jacob Carlborg <doob@me.com> wrote:
> 
> Something like: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
> 

Speaking of, how's that coming along?

July 18, 2012
>
> Something like: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

I am aware of the Orbit project, but what Jigsaw will do for Java, and what similar built-in module versioning in other languages do, is to give control of pieces of large software systems. Having module version as part of the language will give tools like Orbit a nice, standardized way to know what is the module version of a D source file it is currently processing. Later on, it may help compilers create SO/DLL version information if a certain module becomes a library...
Say you have a product, and you want to provide support for all legacy versions. One way to that is to put all old(er) versions of a module into a single library. If the module is not versioned, you would have to use external module information, typically stored in bunch of config files, and what is worse is quite often, if you lose these files, you have no idea what module version it was... (Unless you are pedantic, and write that information in the header comment of the module)

I use Maven a lot, every day, Jigsaw is not a replacement for Maven, it is a help to Maven, coming from the language itself.
July 18, 2012
> Go solves the problem by refusing all notion of dynamic linking and
> insisting on static linking of all applications.

God, I feel sorry for programmers who use Go, in that case...
July 18, 2012
On Wednesday, 18 July 2012 at 09:59:03 UTC, Marco Leise wrote:
> Am Wed, 18 Jul 2012 10:24:36 +0100
> schrieb Russel Winder <russel@winder.org.uk>:
>
>> Go solves the problem by refusing all notion of dynamic linking and
>> insisting on static linking of all applications.
>
> ... not possible? While I learned a while back that system calls exist and are not dynamically linked, I wonder how Go goes about:
>
> * basic system libraries (static linking to kernel32.dll?)
> * executable bloat from large OO toolkits like Qt

Don't flame me, just giving the typical set of answers in gonuts,
which you can easily find when searching for .so/.dll discussions.

Use strip to reduce executable size.

> * increased memory footprint by not allowing shared instances of DLLs/SOs
> * modular development (e.g. separating "server" and "client" code in games)

Separate code in common packages, while generating separate executables.

> * dynamically loadable plugins/extensions

From the security point of view loadable plugins are not good.

Better make use of IPC to communicate between plugins.

If you need performance, make use of shared memory as IPC mechanism,
which incidentally invalidates the security reasons.

> * security and bug fixes to libraries used in dozens of programs
>   (-> recompile of all library users ?)

yes
July 18, 2012
On 2012-07-18 12:07, Nick Sabalausky wrote:

> Speaking of, how's that coming along?

I haven't been working on that for a while. I've been working on DStep. The most basic functionality is there:

* Creating packages
* Installing packages
* Downloading packages
* Uploading packages

Although no real dependency algorithm is implemented yet. I think there's a really simple one, if I recall correctly.

https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg


July 18, 2012
On 2012-07-18 12:23, Dejan Lekic wrote:

> I am aware of the Orbit project, but what Jigsaw will do for Java, and
> what similar built-in module versioning in other languages do, is to
> give control of pieces of large software systems. Having module version
> as part of the language will give tools like Orbit a nice, standardized
> way to know what is the module version of a D source file it is
> currently processing. Later on, it may help compilers create SO/DLL
> version information if a certain module becomes a library...
> Say you have a product, and you want to provide support for all legacy
> versions. One way to that is to put all old(er) versions of a module
> into a single library. If the module is not versioned, you would have to
> use external module information, typically stored in bunch of config
> files, and what is worse is quite often, if you lose these files, you
> have no idea what module version it was... (Unless you are pedantic, and
> write that information in the header comment of the module)
>
> I use Maven a lot, every day, Jigsaw is not a replacement for Maven, it
> is a help to Maven, coming from the language itself.

Yeah, sure. With language support we could do much more. Orbit is focused at working without language support, at least as a start.

-- 
/Jacob Carlborg


July 18, 2012
Am Wed, 18 Jul 2012 11:56:45 +0200
schrieb "Paulo Pinto" <pjmlp@progtools.org>:

> Last time I checked, I could compile Java and C# to native code if I wished to do so.
> 
> --
> Paulo

Forum.getUserByName("Paulo Pinto").addAttribute("nit-picky"); ;)

-- 
Marco

July 18, 2012
On Wednesday, 18 July 2012 at 13:55:10 UTC, Marco Leise wrote:
> Am Wed, 18 Jul 2012 11:56:45 +0200
> schrieb "Paulo Pinto" <pjmlp@progtools.org>:
>
>> Last time I checked, I could compile Java and C# to native code if I wished to do so.
>> 
>> --
>> Paulo
>
> Forum.getUserByName("Paulo Pinto").addAttribute("nit-picky"); ;)

Yeah, I guess I deserve it. :)
July 19, 2012
On Wednesday, 18 July 2012 at 08:08:21 UTC, Dejan Lekic wrote:
> There are several places for D module system to improve.
> One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion.
>
> Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has.
>
> More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
>
> Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important.
>
> I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it...
>
> Kind regards

I'd say that this is going in the wrong direction.
I read an article a while ago that was really enlightening about this subject. The gist was that a module system is the wrong abstraction. Modules are an artifact of procedural thinking in that they are global. This hurts security, testability, etc.

Here's the link: bracha.org/newspeak-modules.pdf
July 19, 2012
On 2012-07-19 11:18, foobar wrote:

> I'd say that this is going in the wrong direction.
> I read an article a while ago that was really enlightening about this
> subject. The gist was that a module system is the wrong abstraction.
> Modules are an artifact of procedural thinking in that they are global.
> This hurts security, testability, etc.
>
> Here's the link: bracha.org/newspeak-modules.pdf

Does it suggest a better approach?

-- 
/Jacob Carlborg