July 19, 2012
On Thu, Jul 19, 2012 at 01:34:31PM +0200, Jacob Carlborg wrote:
> 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?
[...]

I skimmed the paper briefly. Correct me if I'm misreading it, but the approach it proposes is based on identifying classes with modules, and requires that class names be dynamically bound; in particular, superclasses are dynamically bound.  I don't think this will work in D's framework.


T

-- 
Дерево держится корнями, а человек - друзьями.
July 20, 2012
On Wednesday, 18 July 2012 at 11:21:08 UTC, Paulo Pinto wrote:

>> * dynamically loadable plugins/extensions
>
> From the security point of view loadable plugins are not good.
>
> Better make use of IPC to communicate between plugins.
>

Since we kind of have a "never recover from error"-policy that's the only way to have plugins in D too, if you want to have plugins crash your main application.
July 21, 2012
Russel Winder <russel@winder.org.uk> writes:
>> > 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...
>
> Isn't the real question why is the same dynamic library linking problem happening again. Has nothing been learned from UNIX shared objects and Windows DLLs?

ELF (aka "unix") shared objects actually do support versioned symbols (and have since at least 1999) though they're not default and using them makes building a shared library somewhat more complex, as you have to tell the linker about ABI versions. But with properly done versioned symbols, linking two different versions of the same shared library into the same process space is perfectly safe; the C library itself uses it, for instance:

wouter@carillon:~$ objdump -T /lib/x86_64-linux-gnu/libc.so.6  | head -n 20

/lib/x86_64-linux-gnu/libc.so.6:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
000000000001eb80 l    d  .text	0000000000000000              .text
000000000037d738 l    d  .tdata	0000000000000000              .tdata
0000000000000000      DO *UND*	0000000000000000  GLIBC_PRIVATE _rtld_global
0000000000000000      DO *UND*	0000000000000000  GLIBC_PRIVATE __libc_enable_secure
0000000000000000      DF *UND*	0000000000000000  GLIBC_2.3   __tls_get_addr
0000000000000000      DO *UND*	0000000000000000  GLIBC_PRIVATE _rtld_global_ro
0000000000000000  w   D  *UND*	0000000000000000              _dl_starting_up
0000000000000000      DO *UND*	0000000000000000  GLIBC_PRIVATE _dl_argv
00000000000709d0 g    DF .text	0000000000000115  GLIBC_2.2.5 putwchar
000000000008bbf0 g    DF .text	000000000000001e  GLIBC_2.2.5 __strspn_c1
00000000000ec750 g    DF .text	0000000000000017  GLIBC_2.4   __gethostname_chk
000000000008bc10 g    DF .text	000000000000001a  GLIBC_2.2.5 __strspn_c2
00000000000f2660 g    DF .text	00000000000000a5  GLIBC_2.2.5 setrpcent
0000000000093760 g    DF .text	000000000000000a  GLIBC_2.2.5 __wcstod_l
000000000008bc30 g    DF .text	0000000000000022  GLIBC_2.2.5 __strspn_c3
00000000000d8c70 g    DF .text	0000000000000025  GLIBC_2.3.2 epoll_create

the GLIBC_* thingies (apart from the GLIBC_PRIVATE ones) are symbol versions. As you can see, it's even safe to have multiple versions in the same shared object, and (though it's not shown here) you can have multiple implementations of a particular symbol (but with different versions) in one shared object.

For some details on how it works, see http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/symversion.html

> Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications.

"General Motors solves the problem of fatal car crashes by building cars without engines"

That's not a solution, that's avoiding the issue.

Having said that, doing shared libraries properly is fairly complex, so it's not necessarily a bad idea to push the problem into the future until you've thought about it a lot; otherwise you'll probably end up with a broken solution.

> Certainly Gradle and Maven support this idea very well.  Sadly Make, CMake, Autotools, SCons, Waf,… tend to delegate the problem to someone else.

autotools has libtool, which does the shared object stuff, and which can do symbol versioning.

I don't know about cmake; and scons and waf are both crap, so it's not surprising they've not even heard of symbol versioning.

Make, of course, is a programming language for writing build systems, it's not a build system by itself.

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula:

pi zz a
July 21, 2012
On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote:
>> For those that don't know .NET, due to the DLL Hell experience, Microsoft
>> has built version support in the CLR from day 1.
>
> But, as ever, Microsoft see things like this as a way to try and get
> everyone to use Windows via proprietary lock-in rather than by trying to
> educate people about possible solutions.

AFAIK MS tried to use java, but they wasn't allowed to do it. They had to invent a completely alternative solution. And .net is a possible solution, and MS educates people about it.

Also versioning of components is done by COM for ages, though the application has to be designed and written with COM in mind. Components don't even have to be implemented in the same language nor reside in the same process, nor on the same machine.
July 21, 2012
On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote:
>> For those that don't know .NET, due to the DLL Hell experience, Microsoft
>> has built version support in the CLR from day 1.
>
> But, as ever, Microsoft see things like this as a way to try and get
> everyone to use Windows via proprietary lock-in

Also why mono exists, if it's meant to be a lock-in?
July 21, 2012
"Kagamin" <spam@here.lot> writes:

> On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote:
>>> For those that don't know .NET, due to the DLL Hell experience,
>>> Microsoft
>>> has built version support in the CLR from day 1.
>>
>> But, as ever, Microsoft see things like this as a way to try and get
>> everyone to use Windows via proprietary lock-in rather than by
>> trying to
>> educate people about possible solutions.
>
> AFAIK MS tried to use java, but they wasn't allowed to do it.

They were, but they had to make changes -- and that, they weren't allowed to do.

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula:

pi zz a
July 21, 2012
On Sat, 2012-07-21 at 11:26 +0200, Kagamin wrote:
[…]
> AFAIK MS tried to use java, but they wasn't allowed to do it. They had to invent a completely alternative solution. And .net is a possible solution, and MS educates people about it.

Microsoft changed the Java Virtual Machine (JVM) on Windows and Sun
objected to them doing this. Sun's position was that the JVM should be
the same on all platforms – which is an entirely reasonable position for
them to take.  Microsoft didn't think so and tried to persevere with
changing the JVM so Sun took them to court and won. Which was right.
Microsoft then created the CLR and C# which seems fine. The problem for
C# is that Microsoft marketing has put about FUD for anyone using C# on
a platform other than Windows.

But this has nothing to do with D!

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


July 22, 2012
On Sat, 2012-07-21 at 02:17 +0200, Wouter Verhelst wrote: [...]
> I don't know about cmake; and scons and waf are both crap, so it's not surprising they've not even heard of symbol versioning.

I disagree, I think SCons and Waf (along with Gradle) make Make, CMake, Autotools, etc., etc. look like "past their use-by date" tools from the 1970s. You have to justify your opinion that they are "crap", simply saying they are does not make it so.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


July 22, 2012
Russel Winder <russel@winder.org.uk> writes:

> On Sat, 2012-07-21 at 02:17 +0200, Wouter Verhelst wrote: [...]
>> I don't know about cmake; and scons and waf are both crap, so it's not surprising they've not even heard of symbol versioning.
>
> I disagree, I think SCons and Waf (along with Gradle) make Make, CMake, Autotools, etc., etc. look like "past their use-by date" tools from the 1970s. You have to justify your opinion that they are "crap", simply saying they are does not make it so.

(this is fairly off-topic here, so I won't comment on this subthread anymore -- please reply by private mail if you want more details)

Waf wants you to keep the entire waf source inside your distribution tarball. This makes it extremely hard for a distribution to update all their packages for, say, security issues in waf, and makes your distribution tarball huge for no good reason. Additionally, waf has a tendency to break API every other release last I checked, which makes it difficult to upgrade. I happen to think the waf maintainer is fairly nuts too, but that's a personal opinion. I haven't looked close enough at waf to give you much detail about it, however.

SCons happened to be used by a package I used to maintain for Debian. It lacks a number of fairly important features, such as the ability to cross-build, do staged installs (i.e., something like "make DESTDIR=/tmp install" with automake), and a number of other things. Additionally, for the things it does support, the fact that you can just inject arbitrary python code everywhere means that in most cases people using SCons for their build system will (inadvertently?) break it, since they don't know about the feature or think it doesn't matter for their project. It's just a pain to use for people building software with it who have nonstandard needs.

Autotools, while a bit warty in some areas, actually works. Once I read the manual (which, granted, is something that shouldn't be necessary in the first place) and understood how it worked, I've never wanted to use anything else anymore.

There are many people out there who think they can do a better job than autotools, and they all come up with a substandard YABAR[1]. I'll be the first to agree that autotools could use *quite* some improvement in the usability department, but replacing a body of code which has been 20 years in the making so you come up with similar functionality isn't something you can do in two weeks of coding. Yes, granted, waf and SCons have been worked on for a while longer than that. Still.

[1] Yet Another Bloody Autotools Replacement

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula:

pi zz a
1 2 3
Next ›   Last »