You've answered what I was just asking to Lucas

Le 03/07/2016 à 13:07, IOhannes m zmölnig a écrit :

hi,

On 07/03/2016 08:48 AM, Lucas Cordiviola wrote:

...

Type “missing” in deken`s search bar. Then put all dlls in the pd/bin directory.

while i appreciate the initiative to provide missing system libraries, i think this is the wrong way to do it.

#1 a deken package should be self-contained. if a given deken package lacks a library (e.g. libpthreadGCC3.dll) then it should provide that library itself. (alternatively, deken could be (theoretically; practically i see a number of hurdles) enhanced to explicitely state such dependencies (so installing "foo" would also install "pthreadGCC3")

#2 a deken package must be installable by deken. the requierement to "then put all the dlls into pd/bin" contradicts this. until deken can be told to install into pd/bin, i think that though shall not abuse the deken package system for such things.

i'd therefore rather have the 'missingDLLs' package removed from puredata.info. we *should* come up with a proper solution for the problem though.

fmasdr IOhannes

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

On 07/03/2016 03:06 PM, patrice colet wrote:

Le 03/07/2016 à 13:07, IOhannes m zmölnig a écrit :

...

#1 a deken package should be self-contained. if a given deken package lacks a library (e.g. libpthreadGCC3.dll) then it should provide that library itself. (alternatively, deken could be (theoretically; practically i see a number of hurdles) enhanced to explicitely state such dependencies (so installing "foo" would also install "pthreadGCC3")

#2 a deken package must be installable by deken. the requierement to "then put all the dlls into pd/bin" contradicts this. until deken can be told to install into pd/bin, i think that though shall not abuse the deken package system for such things.

Do you think it's possible for deken to:

1° add pd/bin to system's path, then pd pdsend and pdreceive will work with no pain in ms-dos console

this should be done by pd installer but for the moment I believe it doesn't,

since when are pdsend.exe and pdreceive.exe broken? if this is true, this is a rather severe bug in the w32 package of Pd.

so deken could at least resolve this.

hmm. whether it *could* is probably secondary. if deken could fix w32 security breaches, i would still be opposed to using it for these kind of things :-)

2° add dependencies to a place declared in system's path

admin rights would only be required when installing deken or last pd-vanilla

if by system path you mean something like "C:\Windows", then putting things there is asking for trouble, as this is likely to break unrelated software ("dependency hell").

apart from that: what deken currently does is to download zip-files and extract those zip-files somewhere in Pd's search path. this is a simple task, and deken was always meant to be simple. i don't see a way to keep that design and allow for things you ask (unzip doesn't allow such quirks)

so: i think the way to go is to create self-contained deken packages, that do not require anything outside their directory.

i'm under the vague impression that there *is* a way to have dll-dependencies live besides the dll (rather than the calling binary). though i also seem to remember that hans researched that and didn't come up with a proper solution (but then, Pd-extended could live without)

also, if it's absolutely impossible to have pthreadGCC2.dll live besides foo.dll (and have it instead live besides pd.exe), then i think the proper solution would be to re-compile foo, so it depends on the pthread-implementation that already comes with Pd.

gfmsrada IOhannes

Le 03/07/2016 à 20:46, IOhannes m zmölnig a écrit :

Do you think it's possible for deken to:

...

1° add pd/bin to system's path, then pd pdsend and pdreceive will work with no pain in ms-dos console

this should be done by pd installer but for the moment I believe it doesn't,

since when are pdsend.exe and pdreceive.exe broken? if this is true, this is a rather severe bug in the w32 package of Pd.

They are not litteraly broken, they just don't respond in ms-dos console after a fresh install from installer unless we navigate with the console to pd/bin or if it's added to environment variables, same for pd.com.

I'd rather consider that more like a missing feature than a bug, it's one one the things that doesn't make pd as reliable as we have it on linux.