View mode: basic / threaded / horizontal-split · Log in · Help
July 18, 2012
Orbit (Was: Re-thinking D's modules)
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
Re: Re-thinking D's modules
>
> 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
Re: Re-thinking D's modules
> 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
Re: Re-thinking D's modules
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
Re: Orbit (Was: Re-thinking D's modules)
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
Re: Re-thinking D's modules
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
Re: Re-thinking D's modules
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
Re: Re-thinking D's modules
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
Re: Re-thinking D's modules
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
Re: Re-thinking D's modules
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
1 2 3
Top | Discussion index | About this forum | D home