From: D Herring
Subject: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <gh4tkp$und$1@aioe.org>
On MSWin, Clisp can follow shortcuts in asdf:*central-registry* to
find the actual system definitions, just like unix symlinks. In other
words (truename symlink) returns the path of the target file.
Could Windows (or implementation-knowledgeable) users help fill in the
following table? Just need "yes", "no", or "NA" ("not applicable",
e.g. absolutely won't run on MSWin).
Does this implementation support ASDF shortcuts?
- allegro =
- abcl =
- cmucl =
- clozure =
- corman =
- ecl =
- gcl =
- clisp = yes
- lispworks =
- scieneer =
- sbcl =
- other?
Thanks,
Daniel
Didn't try this. I looked to CLISP manual and find no mention of it.
Is it a property of CLISP or maybe cygwin?
I think this problem could be fixed very easily and portably on
windows.
1. Write a tiny .exe which dereferences shortcut and prints
derefernced file name to a file or to a stdout.
2. asdf:run-shell-command
3. Modify sysdef-central-registry-search
Well, I've done almost all...
http://paste.lisp.org/display/71516
Now you can use shortcuts with asdf instead of symlinks.
At least, in Lispworks.
In reply to OPs question, lispworks does not resolve shortcuts.
From: D Herring
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <gh7f70$oed$1@aioe.org>
budden wrote:
> Well, I've done almost all...
>
> http://paste.lisp.org/display/71516
>
> Now you can use shortcuts with asdf instead of symlinks.
> At least, in Lispworks.
Thanks. I might have a use for this in the not-too-distant future.
> In reply to OPs question, lispworks does not resolve shortcuts.
Ok.
- Daniel
From: Kaz Kylheku
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <20081219011149.299@gmail.com>
On 2008-12-03, budden <········@gmail.com> wrote:
> Well, I've done almost all...
>
> http://paste.lisp.org/display/71516
>
> Now you can use shortcuts with asdf instead of symlinks.
> At least, in Lispworks.
Ouch! You have to use COM objects to resolve a link?
Please tell me that this doesn't actually go out to the registry to
map the class ID to the right library!
Microsoft stupidity seems bottomless at times.
By the way, I don't think you can put the LGPL license on code that you
plagiarized from MSDN. In spite of the changes you me to it, it's
still a work derived from something that anyone can use and redistribute.
http://msdn.microsoft.com/en-us/library/bb776891(VS.85).aspx#Shellink_Link_Resolution
``Copyright 2008 Denis Budyak,'' yeah right! :)
What gave it away is the stupid hungarian notation, and the insane use of
nesting to avoid using goto.
You added a little bug I see. You added a CoInitialize call, just in case the
calling thread hasn't called it. But you didn't match it with a CoUninitialize.
These calls do not neatly nest, either; you have to check the return value to
see whether your CoInitialize is actually the first call that did the COM
initialization for this thread, and only in that case do the CoUninitialize.
It's better to document this and leave it to the caller:
// Like a million and one other Microsoft functions, MyFunction
// requires CoInitialize to have been called, or it won't work!
// You probably already called this somewhere, so you probably
// don't have to do anything.
I see you've done a few other pointless or silly things.
The function takes a TCHAR string, but then assumes it's WCHAR --- no
conversion is applied to this input. You don't seem to understand Win32
character issues properly.
TCHAR is a hack which allows code to be switched at compile time to use narrow
or wide characters. The API functions you call are switched at compile time
too. E.g. GetProcAddress becomes either GetProcAddressA or GetProcAddressW,
thanks to the magic of C preprocessor macros.
If in such code there are places where you want to work specifically with wide
characters, you have to specifically call the wide functions (using that ugly
little W suffix). I see you did that in one place, but everywhere else, you're using the plain names on WCHAR strings, which means ``this code only makes sense when compiled UNICODE''. In which case, don't use TCHAR anywhere!
BTW I like how you changed something that was a pointer in the original code to
an array, yet still call it ``lpszPath''. Arrays /are/ pointers, right?
That's the beauty of the Microsoft notation: for very good reasons, people
don't want to edit the name of an object when they change its type.
From: David Golden
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <gh8q03$uat$1@aioe.org>
Kaz Kylheku wrote:
> Ouch! You have to use COM objects to resolve a link?
>
> Please tell me that this doesn't actually go out to the registry to
> map the class ID to the right library!
>
> Microsoft stupidity seems bottomless at times.
>
well, windows vista has real...ish symlinks. "mklink" on the command
line.
http://en.wikipedia.org/wiki/Symbolic_link#Windows_Vista_symbolic_link
Windows explorer shell shortcuts are NOT symlinks, they're more
analogous to free desktop .desktop files. On linux, you'd probably
want to instantiate a kde or gnome object to follow a .desktop file
too, unless you felt like writing your own parser
http://standards.freedesktop.org/desktop-entry-spec/latest/
On 2008-12-04, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-12-03, budden <········@gmail.com> wrote:
>> Well, I've done almost all...
>>
>> http://paste.lisp.org/display/71516
>>
>> Now you can use shortcuts with asdf instead of symlinks.
>> At least, in Lispworks.
>
> Ouch! You have to use COM objects to resolve a link?
No, the shortcut format is documented and can be parsed using portable Lisp
code. ASDF patch here: http://www.lichteblau.com/blubba/shortcut/asdf.diff
d.
> http://www.lichteblau.com/blubba/shortcut/asdf.diff
Wow, nice! I didn't try this yet, but I'll do. If it works, it is
definitely better than my. In this case, I'll throw mine away. This
what I'd say about shortcut management itself.
What goes to overall organization, I'm sure it'd be better not to
patch asdf at all, but make a separate file which is loaded after asdf
and installs a new search function to asdf (see my paste). This is
much better with regards to maintainability unless asdf maintainers
accept this patch to the main branch. E.g. you patch asdf, then asdf
is re-issuid. You need to re-patch it. Messy.
Anyway, if one uses both asdf and asdf-install, this patch might lead
to a great confusion, as
asdf-install has its own way to help win32 users:
http://common-lisp.net/project/asdf-install/tutorial/setup.html#load-asdf-install
There are reasons why this way is not good though (consider you have
two versions of the same system in the "site" subdir). Windows user
would likely have this feature enabled already and asdf will find his
system even without any shortcut. It leads to a confusion and should
be disabled prior to using shortcuts.
From: D Herring
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <gha70q$r12$1@aioe.org>
David Lichteblau wrote:
> On 2008-12-04, Kaz Kylheku <········@gmail.com> wrote:
>> On 2008-12-03, budden <········@gmail.com> wrote:
>>> Well, I've done almost all...
>>>
>>> http://paste.lisp.org/display/71516
>>>
>>> Now you can use shortcuts with asdf instead of symlinks.
>>> At least, in Lispworks.
>> Ouch! You have to use COM objects to resolve a link?
>
> No, the shortcut format is documented and can be parsed using portable Lisp
> code. ASDF patch here: http://www.lichteblau.com/blubba/shortcut/asdf.diff
Any idea why that isn't in mainline ASDF?
Thanks,
Daniel
On Dec 4, 5:34 am, Kaz Kylheku <········@gmail.com> wrote:
> These calls do not neatly nest, either; you have to check the return value to
> see whether your CoInitialize is actually the first call that did the COM
> initialization for this thread, and only in that case do the CoUninitialize.
That is incorrect. `CoUninitialize' must be called if and only if the
call to `CoInitialize' was successful. If the COM library was already
initialized (and the concurrency model is the same) then
`CoInitialize' will return `S_FALSE', which indicates success. Hence,
`CoUninitialize' must be called in this case.
Ariel
Hallo Kaz, group!
I don't know what should I have written in a copyright/licensing
section. Maybe I should have add a link to an initial MSDN article
from which 99% of code goes. I am sure everyone knows the source of
the code and I didn't intend to hide this. I am very unaware or
licensing problems. You know, Russia, where bears are walking across
the streets... Advice me what to do.
> Ouch! You have to use COM objects to resolve a link?
I don't know if I really have to. I had a problem, searched the
inet, found a solution. It was the first solution I found. Maybe not
the best one. It works, that's enough for now.
> You added a little bug I see. You added a CoInitialize call, just in case the calling thread hasn't called it.
I don't think it is a bug. My paste is a complete source of .exe
file (maybe I should have add .vcproj file too...). No caller is
implied, no need to call CoUninitialize. Correct me if I am wrong.
> The function takes a TCHAR string, but then assumes it's WCHAR --- no conversion is applied to this input. You don't seem to understand Win32 character issues properly.
Maybe. But _tmain is a wizard generated main function. I don't think I
may change types of its parameters. I use "unicode character set" in a
project settings. _TCHAR is defined by
typedef wchar_t _TCHAR;
in this configuration. No warnings are issued on build. All seems to
be ok. lnk_resolve now works on windows XP and understands Cyrillic
symbols too (this means it deals correctly with characters), but fails
to work on Windows 98. If someone needs it to work under Windows 98,
one can either correct it himself or inform me and then I'll get
deeper in a character pecularities.
> BTW I like how you changed something that was a pointer in the original code to an array, yet still call it ``lpszPath''.
In fact, I did all this in a great rush. I see there is defsystem,
clbuild, asdf and now there is Mudballs. It looks like a world after
Babylonian tower destruction. I just have finished huge 10$ lisp job,
massive 3$ per hour and I think I'll be unable to find ANY lisp job if
the things will go on this way. I need to save the time and (non-gc-
able) grey cells allocation I invested in lisp. ASDF is the strongest
build system now, but it is too weak. I only want here to be
_the_only_ de-facto standard build system. I have read Mudballs
rationale and found no exuse for it to exist. I don't have NIH
syndrom. I need just a working build system and if asdf resists to
changes, I'll just can make a fork or a set of extensions to it as I
did to iterate.
At the same time, I have two contracts, but going to gen unemployed in
a two weeks, etc, etc. I simply got no time to rename identifiers in a
working utilities.
From: D Herring
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <gh7esn$nhc$1@aioe.org>
budden wrote:
> Didn't try this. I looked to CLISP manual and find no mention of it.
> Is it a property of CLISP or maybe cygwin?
Its a property of clisp. You can find hints of it in various
CLisp/ASDF writings scattered around the internet[1]. Works on WinXP
with no cygwin installed.
> I think this problem could be fixed very easily and portably on
> windows.
> 1. Write a tiny .exe which dereferences shortcut and prints
> derefernced file name to a file or to a stdout.
> 2. asdf:run-shell-command
> 3. Modify sysdef-central-registry-search
Another approach is to have central-registry-search scan
subdirectories of an install path. Rather like "C:\Program Files".
Again, see [1].
[1] http://www.cliki.net/asdf
- Daniel
On Dec 3, 4:15 am, D Herring <········@at.tentpost.dot.com> wrote:
> On MSWin, Clisp can follow shortcuts in asdf:*central-registry* to
> find the actual system definitions, just like unix symlinks. In other
> words (truename symlink) returns the path of the target file.
>
> - ecl =
ECL does not support natively Windows shortcuts. Maybe the cygwin or
mingw libraries can fake it letting them look like ordinary symlinks,
but I did not test this.
Juanjo
From: D Herring
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <gh7ffa$p57$1@aioe.org>
Juanjo wrote:
> On Dec 3, 4:15 am, D Herring <········@at.tentpost.dot.com> wrote:
>> On MSWin, Clisp can follow shortcuts in asdf:*central-registry* to
>> find the actual system definitions, just like unix symlinks. In other
>> words (truename symlink) returns the path of the target file.
>>
>> - ecl =
>
> ECL does not support natively Windows shortcuts. Maybe the cygwin or
> mingw libraries can fake it letting them look like ordinary symlinks,
> but I did not test this.
Ok. Thanks for the info.
Looking at budden's (LGPL) code, this might be an easy feature to add.
- Daniel
On Dec 4, 3:32 am, D Herring <········@at.tentpost.dot.com> wrote:
> Juanjo wrote:
> >ECLdoes not support natively Windows shortcuts. Maybe the cygwin or
> > mingw libraries can fake it letting them look like ordinary symlinks,
> > but I did not test this.
>
> Looking at budden's (LGPL) code, this might be an easy feature to add.
Yes, indeed. You would not need an external program and the function
could be either embedded in the core library (ECL) or in the ASDF
module.
Juanjo
http://www.lichteblau.com/blubba/shortcut/
There is a patch for asdf to use shortcuts already.
> You would not need an external program and the function
could be either embedded in the core library (ECL) or in the ASDF
module.
For this question it is true, but in general, I disagree totally.
External program called via pipe (or even via external file to which
it is redirected) is more reliable and portable. No bugs in the
program harm lisp monster image.
On Dec 12, 2:36 pm, budden <···········@mail.ru> wrote:
> For this question it is true, but in general, I disagree totally.
> External program called via pipe (or even via external file to which
> it is redirected) is more reliable and portable. No bugs in the
> program harm lisp monster image.
If you worry that a bug pops up in a 20 lines program, then something
is wrong :-) Besides, you may have also serious problems in code that
communicate with a subprogram, leading to the CL image hanging on the
output, getting corrupt communication, etc. That is not an excuse.
In the practical case of ASDF, with just minor tweaks, the same C file
could be used both in a standalone program and as a subroutine of a
library, so that shipping the same code one would get the subprogram
or the code to embed in an ECL fasl file.
Juanjo
From: Raymond Wiker
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <m263lm8xxk.fsf@RAWMBP.local>
budden <···········@mail.ru> writes:
> http://www.lichteblau.com/blubba/shortcut/
> There is a patch for asdf to use shortcuts already.
>
>> You would not need an external program and the function
> could be either embedded in the core library (ECL) or in the ASDF
> module.
>
> For this question it is true, but in general, I disagree totally.
> External program called via pipe (or even via external file to which
> it is redirected) is more reliable and portable. No bugs in the
> program harm lisp monster image.
Calling an external program via a single pipe is trivial; if
you need to use pipes for both input & output you're likely to end up
doing a lot of work just to avoid deadlocks...
> Calling an external program via a single pipe is trivial; if
> you need to use pipes for both input & output you're likely to end up
> doing a lot of work just to avoid deadlocks...
In many cases, you can just redirect output to file and read this file
from lisp. BTW, there are http://gnuwin32.sourceforge.net/
which contain readlink.exe and this looks like to be a better
substitute of my MSDN-derived code.
But I think that's enough for the topic. Our current problem with
shortcuts is solved (in theory). The only thing we need is to put this
to practice and advertise it in a degree sufficient for stopping
further attempts to reinvent the weel. I don't think patching asdf is
a good idea. I'd like to have some "addition" or "extension" instead
which sets up in a layered manner and improves asdf action. When I
take time, I hope I'll take the latter patch mentioned, add some of
asdf utilities, add some of my code and publish it as a package/darcs
repo. I suggest to discuss it further here:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/65cac83ea3a19271/7c28ba5af7ae1f09?#7c28ba5af7ae1f09
Hi all!
One more idea for improving asdf on windows. I'm not sure shortcuts
are very convinient way
to go, at all. Why not create just a simple sexp file with names
of .asd systems you want asdf to see?
In this case, we write the following functions:
(defun collect-asd-files (source-directories &key rewrite-init-file)
"Walks directories and writes to ~/asdf_systems. If rewrite-init-
file is true,
rewrites init file. If nil, prints new systems not found in ~/
asdf_systems"
(cl-fad:walk-directory ...))
(defun check-non-ambiguity-of-asdf-systems-dot-lisp ()
(= (length (remove-duplicates ...) ...)
(defun find-asd-file-in-asdf-systems-dot-lisp (system-name)
(with-open-file (...) (read ...) (find-if ...)))
In this case, you can add #+feature controls to that file.
E.g. it might look like this:
((:feature+ :world-1.0 (:system :iterate #p"c:/source1/iterate/
iterate.asd"))
(:feature+ :world-2.0 (:system :iterate #p"c:/source2/iterate-
keywords/iterate.asd"))
(:system :cl-utilities #p"c:/source3/cl-utilities/cl-utilities.asd"))
(:include #p"c:/user/more_asdf_systems") ; might introduce more
convinience and more mess. Hesitating
)
You see I do not use #+. This is done to simplify patching. All file
then can be read as one expression regardless of
*features*, patched (e.g. by asdf-install) and saved back.
Additionally, I can use more flexible logical expressions than #
+feature
suggests.
Is someone interested in having this? For me, it looks so sweet that I
wonder why no-one done this already.
Look, this is extremely portable (easy cross-OS, cross-implementation
portability) and extremely manageable.
Currently I have all asdf problems solved with gnuwin32 readlink.exe.
But if someone inspire me,
I'll hack this with a pleasure.
---------------
$5/hour lisp freelancer. Hire me before my rate grew!
budden <···········@mail.ru> writes:
> Hi all!
>
> One more idea for improving asdf on windows. I'm not sure shortcuts
> are very convinient way
> to go, at all. Why not create just a simple sexp file with names
> of .asd systems you want asdf to see?
Of course. When I write a real program (that will be deployed and
thus that will need maintaining), I tend to load systems like this:
(let ((asdf:*central-registry* (list (merge-pathnames #P"split-sequence/" *project-base* nil))))
(asdf:oos 'asdf:load-op :split-sequence))
(let ((asdf:*central-registry* (list (merge-pathnames #P"md5-1.8.5/" *project-base* nil))))
(asdf:oos 'asdf:load-op :md5))
Which kind of defeats the purpose... But I least I know exactly what
(version of each system) I load and what I need to maintain.
--
__Pascal Bourguignon__
From: D Herring
Subject: Re: Help wanted: CL, ASDF, and MSWin shortcuts
Date:
Message-ID: <gh7fk8$p57$2@aioe.org>
Current status:
Does this implementation support ASDF shortcuts?
- allegro =
- abcl =
- cmucl =
- clozure =
- corman =
- ecl = no
- gcl =
- clisp = yes
- lispworks = maybe; needs helper app
- scieneer =
- sbcl =
- other?
Feel free to fill in the blanks.
- Daniel