Menu
▾
▴
tcllib-devel
|
From: Andreas K. <aku...@sh...> - 2005-10-07 00:46:32
|
[Sent again from my home account as the mail from office has not appeared yet]. > > then update the version number, tag the state, and generate a > > pre-release distribution for testing Friday to Sunday. The only things > > we will fix in that interval will be very major bugs and showstoppers. The Tcllib CVS has been tagged and __ pre-release __ archives have been created. They can be found at http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.tar.gz http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.tar.bz http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.zip http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8.kit Please give them a whirl. The CVS is still frozen. -- So long, Andreas Kupries <aku...@sh...> <http://www.purl.org/NET/akupries/> Developer @ <http://www.activestate.com/> ------------------------------------------------------------------------------- |
|
From: Andreas K. <and...@Ac...> - 2005-10-07 20:05:55
|
And a second set of regenerated pre-release archives. Incorporates Pat's smtp/sasl changes as well, and a bugfix for struct::tree/critcl. The CVS for the module has been retagged as well. The new files are http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.tar.gz http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.tar.bz http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.zip http://www.purl.org/net/akupries/soft/clt-arch/tcllib-1.8-2.kit The CVS is still frozen. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com, a division of Sophos Tel: +1 604 484 6491 |
|
From: Lars <lar...@re...> - 2005-10-10 13:56:06
|
At 02.42 +0200 2005-10-07, Andreas Kupries wrote: >The Tcllib CVS has been tagged and __ pre-release __ archives have been >created. [snip] >Please give them a whirl. I currently have some hours to kill in Never-never-land (in an airport lounge just outside Customs, waiting for a flight that's currently estimated to be two hours late), so why not do some whirling, indeed? So far I've mostly been dealing with the installer, but I thought I'd better start typing things down before I forget... A first problem I had was that the installer doesn't handle permissions. I understand it probably can't, but there could be some advice in INSTALL.txt on how to deal with this. I suspect [exec sudo installer.tcl] doesn't qualify as good practice. Also it could try to catch the error (for me it was the [file mkdir tcllib1.8] that failed first) rather than just error out completely. Next, I'd like to ask where the log ends up (when running the GUI version). I got some curious error messages in the documentation-making-phase (for snit_faq, I think), which however didn't stop the installation. I thought I could come back to it later, but after installation was complete wish just exited, and then the information in the log window was no more. (I think the error said something about a particular string not being a valid return code in the sv_se locale (???).) [Later, after having browsed the installer.tcl code a couple of times, I see that the installer indeed just quits when done. When working in GUI mode, it should first ask the user whether (s)he wants to save the log window contents. An additional alternative could be to dump the log window contents to stdout, though.] Another curious thing is the default locations the installer selects, which had me confused for quite a while. In my system it wants to place things in /System/Library, despite /Library being more appropriate (e.g. being where my wish is located). The logic that appears to be responsible for this is that libpath is set to the last element of tcl_pkgPath, but is that appropriate? Looking at how my tcl_pkgPath is constructed, it mostly goes from specific (e.g. user-installed packages) to general (those provided by the OS vendor), so the things I install should rather go into some of the early entries on this path. Slightly related, but not having any ill effects for me, is the way in which the test for a starkit is being performed. It tests whether [info nameofexecutable] is a prefix of [info library], but it appears to me as the test may miss some cases where this happens. The reason is that I find my [info nameofexecutable] is the non-normalized /usr/bin/../../Library/Frameworks/Tk.framework/Versions/8.4/Resources/Wish Shell.app/Contents/MacOS/Wish Shell whereas the [info library] is normalized to /Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts Perhaps starkits don't normalize their library paths, or perhaps they do, but one should anyway take note of this possibility for errors. Not much actual testing got done, but OTOH these delayed remarks could be useful in a slightly longer timeframe. Lars Hellstr=F6m, now safely home (after far too many hours waiting in airports this weekend; aarrrrgh) |
|
From: Larry W. V. <lv...@ca...> - 2005-10-10 18:32:11
|
Here's the warnings that were mentioned:
Generating /volws/lwv27/ldatae/man/mann/doctoc_api.n
Manpage warning (sectambig): (Sub)Section title "What is a snit::widget?" causes ambiguous
section references.
Manpage warning (sectambig): (Sub)Section title "What is a snit::widgetadaptor?" causes am
biguous section references.
Manpage warning (sectambig): (Sub)Section title "What is a snit::widget?" causes ambiguous
section references.
Manpage warning (sectambig): (Sub)Section title "What is a snit::widgetadaptor?" causes am
biguous section references.
Generating /volws/lwv27/ldatae/man/mann/snitfaq.n
Manpage warning (sectambig): (Sub)Section title "What is a snit::widget?" causes ambiguous
section references.
Manpage warning (sectambig): (Sub)Section title "What is a snit::widgetadaptor?" causes am
biguous section references.
Manpage warning (sectambig): (Sub)Section title "What is a snit::widget?" causes ambiguous
section references.
Manpage warning (sectambig): (Sub)Section title "What is a snit::widgetadaptor?" causes am
biguous section references.
I have only been using the Tcl 8.5 environment for my testing of
extensions - my users don't want extensions to change on them.
So I have some interesting results using the new tcllib release against
Tcl 8.5. I know this isn't a combo that is particularly expected to be
supported - just thought I'd mention it.
I'm using Solaris 9 on a sparc.
There are 20 tcllib test suite failures.
Module: asn
modules/asn/asn.test
- asn 0.4
==== asn-2.19 integer FAILED
==== Contents of test case:
binary scan [asn::asnInteger $i] H* result
list $i [string toupper $result]
---- Result was:
8388608 02050000800000
---- Result should have been (exact matching):
8388608 020400800000
==== asn-2.19 FAILED
==== asn-4.19 enum FAILED
==== Contents of test case:
binary scan [asn::asnEnumeration $i] H* result
list $i [string toupper $result]
---- Result was:
8388608 0A050000800000
---- Result should have been (exact matching):
8388608 0A0400800000
==== asn-4.19 FAILED
plus quite a few more. I won't flood email boxes with them. Just
trying to characterise the types of things that I encountered.
==== counter-avg counter::count FAILED
==== Contents of test case:
counter::init avg
counter::count avg 2.2
counter::count avg 3.3
counter::count avg 9.8
counter::get avg -avg
---- Result was:
5.1000000000000005
---- Result should have been (exact matching):
5.1
==== counter-avg FAILED
and a similar failure in counter-hist.
exif-makernote-19.0 makernote field 19 (afpoint) is optional FAILED
The failure occurs in the FocalPlaneXResolution return value - which is now
returning with 7766.9902912621355 instead of the 7766.99029126 previously
returned. Similar problem appeared with the PlaneYResolution field.
There might be other fields - the output is very long and I wasn't certain
if I was missing a field.
modules/math/fuzzy.test
math::fuzzy 0.2
==== math-fuzzy-ManyCompares-1.1 Compare fails due to missing braces FAILED
:
Removed specific test case to save space here - this isn't a bug
report, just an observation.
:
---- Result was:
1
---- Result should have been (exact matching):
0
==== math-fuzzy-ManyCompares-1.1 FAILED
The profiler 7.2 sortFunctions test failed because the results were returning
with some new elements:
---- Result was:
{::tcl::clock::scan 0} {::tcl::clock::format 0} {::tcl::clock::add 0} {::bar 1} {::foo 2}
---- Result should have been (exact matching):
{::bar 1} {::foo 2}
==== profiler-7.2 FAILED
- SASL::NTLM 1.0.0
==== SASL-NTLM-1.1 NTLM client response FAILED
==== Contents of test case:
list [catch {
set ctx [SASL::new -mechanism NTLM -callback NTLMCallback]
SASL::step $ctx ""
SASL::step $ctx [base64::decode $Chk(2)]
set response [SASL::response $ctx]
SASL::cleanup $ctx
base64::encode -maxlen 0 $response
} res] $res
---- Result was:
0 TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAJoAAAABAgAAAAAAAABE
AE8ATQBBAEkATgB1AHMAZQByAFcATwBSAEsAUwBUAEEAVABJAE8ATsM3zVy9RPyXgqZnr21CfG3mfCDC0+d8VoLTft
Hx9ZaM2NlnEeJBCjvPm4ryx3aR4A==
---- Result should have been (exact matching):
0 TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAJoAAAABAgAAAAAAAEQA
TwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjB
wx6BhHRmspst9GgPOZWPuMITqcxg==
==== SASL-NTLM-1.1 FAILED
==== units-10.1 leading zero is not octal FAILED
==== Contents of test case:
::units::convert 09mm meter
---- Result was:
0.009000000000000001
---- Result should have been (exact matching):
0.009
==== units-10.1 FAILED
So, the worst failure was in the first module, where the new resolution
is causing a lot of test result failures. I suspect a number of the
other failures are similar.
--
Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...><URL: http://www.purl.org/NET/lvirden/ >
Even if explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
-><-
|
|
From: Michael S. <sc...@un...> - 2005-10-10 19:31:55
|
Larry W. Virden schrieb: > Here's the warnings that were mentioned: > I have only been using the Tcl 8.5 environment for my testing of > extensions - my users don't want extensions to change on them. > So I have some interesting results using the new tcllib release against > Tcl 8.5. I know this isn't a combo that is particularly expected to be > supported - just thought I'd mention it. > There are 20 tcllib test suite failures. > > Module: asn > modules/asn/asn.test > - asn 0.4 > > ==== asn-2.19 integer FAILED > ==== Contents of test case: > > binary scan [asn::asnInteger $i] H* result > list $i [string toupper $result] > > ---- Result was: > 8388608 02050000800000 > ---- Result should have been (exact matching): > 8388608 020400800000 > ==== asn-2.19 FAILED > > ==== asn-4.19 enum FAILED > ==== Contents of test case: > > binary scan [asn::asnEnumeration $i] H* result > list $i [string toupper $result] > > ---- Result was: > 8388608 0A050000800000 > ---- Result should have been (exact matching): > 8388608 0A0400800000 > ==== asn-4.19 FAILED > > plus quite a few more. I won't flood email boxes with them. Just > trying to characterise the types of things that I encountered. Those are actually failures in the Tcl 8.5 core, not in the asn package. For reference: http://sourceforge.net/tracker/index.php?func=detail&aid=1272730&group_id=12883&atid=112883 Michael |
|
From: Arjen M. <arj...@wl...> - 2005-10-11 06:47:59
|
"Larry W. Virden" wrote: > > Here's the warnings that were mentioned: > > > ==== counter-avg counter::count FAILED > ==== Contents of test case: > > counter::init avg > counter::count avg 2.2 > counter::count avg 3.3 > counter::count avg 9.8 > counter::get avg -avg > > ---- Result was: > 5.1000000000000005 > ---- Result should have been (exact matching): > 5.1 > ==== counter-avg FAILED > > and a similar failure in counter-hist. > > modules/math/fuzzy.test > math::fuzzy 0.2 > > ==== math-fuzzy-ManyCompares-1.1 Compare fails due to missing braces FAILED > : > Removed specific test case to save space here - this isn't a bug > report, just an observation. > : > > ---- Result was: > 1 > ---- Result should have been (exact matching): > 0 > ==== math-fuzzy-ManyCompares-1.1 FAILED > > > ==== units-10.1 leading zero is not octal FAILED > ==== Contents of test case: > > ::units::convert 09mm meter > > ---- Result was: > 0.009000000000000001 > ---- Result should have been (exact matching): > 0.009 > ==== units-10.1 FAILED > I suspect that these failures are due to the changed handling of numerical values in Tcl 8.5. Doesn't it use tcl_precision = 17 by default? Regards, Arjen |
|
From: Andreas K. <and...@Ac...> - 2005-10-13 19:40:31
|
> Here's the warnings that were mentioned:
> Generating /volws/lwv27/ldatae/man/mann/snitfaq.n
> Manpage warning (sectambig): (Sub)Section title "What is a
> snit::widget?" causes ambiguous
> section references.
> Manpage warning (sectambig): (Sub)Section title "What is a
> snit::widgetadaptor?" causes am
> biguous section references.
> Manpage warning (sectambig): (Sub)Section title "What is a
> snit::widget?" causes ambiguous
> section references.
> Manpage warning (sectambig): (Sub)Section title "What is a
> snit::widgetadaptor?" causes am
> biguous section references.
Yep, some (sub)section tiltes are not unique ... Minor thing. I defered that
to after the release.
> I have only been using the Tcl 8.5 environment for my testing of
> extensions - my users don't want extensions to change on them.
> So I have some interesting results using the new tcllib release against
> Tcl 8.5. I know this isn't a combo that is particularly expected to be
> supported - just thought I'd mention it.
> I'm using Solaris 9 on a sparc.
>
>
> There are 20 tcllib test suite failures.
>
> Module: asn
> modules/asn/asn.test
> - asn 0.4
Known bug with handling of integer numbers in the 8.5 core. This might be
gone now, with the bignum processing merged into the head.
>
> ==== counter-avg counter::count FAILED
> ==== Contents of test case:
>
> counter::init avg
> counter::count avg 2.2
> counter::count avg 3.3
> counter::count avg 9.8
> counter::get avg -avg
>
> ---- Result was:
> 5.1000000000000005
> ---- Result should have been (exact matching):
> 5.1
> ==== counter-avg FAILED
tcl_precision differences
> exif-makernote-19.0 makernote field 19 (afpoint) is optional FAILED
>
> The failure occurs in the FocalPlaneXResolution return value -
> which is now
> returning with 7766.9902912621355 instead of the 7766.99029126 previously
> returned. Similar problem appeared with the PlaneYResolution field.
> There might be other fields - the output is very long and I wasn't certain
> if I was missing a field.
No, these are the floating point elements which differ.
> ---- Result was:
> 1
> ---- Result should have been (exact matching):
> 0
> ==== math-fuzzy-ManyCompares-1.1 FAILED
Arjen knows about it, is waiting for the head to stabilize a bit more in the
number area.
>
>
>
> The profiler 7.2 sortFunctions test failed because the results
> were returning
> with some new elements:
>
> ---- Result was:
> {::tcl::clock::scan 0} {::tcl::clock::format 0}
> {::tcl::clock::add 0} {::bar 1} {::foo 2}
> ---- Result should have been (exact matching):
> {::bar 1} {::foo 2}
> ==== profiler-7.2 FAILED
Yup, because parts of clock are now procedures.
> - SASL::NTLM 1.0.0
>
> ==== SASL-NTLM-1.1 NTLM client response FAILED
> ==== Contents of test case:
>
> list [catch {
> set ctx [SASL::new -mechanism NTLM -callback NTLMCallback]
> SASL::step $ctx ""
> SASL::step $ctx [base64::decode $Chk(2)]
> set response [SASL::response $ctx]
> SASL::cleanup $ctx
> base64::encode -maxlen 0 $response
> } res] $res
>
> ---- Result was:
> 0
> TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVA
> AAAJoAAAABAgAAAAAAAABE
> AE8ATQBBAEkATgB1AHMAZQByAFcATwBSAEsAUwBUAEEAVABJAE8ATsM3zVy9RPyXgq
> Znr21CfG3mfCDC0+d8VoLTft
> Hx9ZaM2NlnEeJBCjvPm4ryx3aR4A==
> ---- Result should have been (exact matching):
> 0
> TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVA
> AAAJoAAAABAgAAAAAAAEQA
> TwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgq
> Znr21CfG3mfCDC0+d8ViWpjB
> wx6BhHRmspst9GgPOZWPuMITqcxg==
> ==== SASL-NTLM-1.1 FAILED
For Pat, no idea.
> So, the worst failure was in the first module, where the new resolution
No, not the resolution, these are integer numbers, not floating point. At
the time this was found we found that the integer numbers in Tcl 8.5 had a
serious bug.
> is causing a lot of test result failures. I suspect a number of the
> other failures are similar.
But most others are something with changes in floating point precision
--
Andreas Kupries <and...@Ac...>
Developer @ http://www.ActiveState.com, a division of Sophos
Tel: +1 604 484 6491
|
|
From: Andreas K. <and...@Ac...> - 2005-10-10 19:06:16
|
> > At 02.42 +0200 2005-10-07, Andreas Kupries wrote: > >The Tcllib CVS has been tagged and __ pre-release __ archives have bee= n > >created. > [snip] > >Please give them a whirl. > > I currently have some hours to kill in Never-never-land (in an airport > lounge just outside Customs, waiting for a flight that's currently > estimated to be two hours late), Oi. > so why not do some whirling, indeed? So > far I've mostly been dealing with the installer, but I thought I'd bett= er > start typing things down before I forget... > > A first problem I had was that the installer doesn't handle permissions. Do you mean by that the installer gets confused by permissions when runni= ng, or that it does not set permissions on the files it installs ? > I understand it probably can't, but there could be some advice in INSTALL.txt > on how to deal with this. We do have commands in Tcl for this, see "file attributes". We will have = to distinguish Windows and Unix, but otherwise we could set permissions. We should possibly discuss what would be good permissions. > I suspect [exec sudo installer.tcl] doesn't > qualify as good practice. Hm. Well, if it finds a proper Tclsh. But in general no. > Also it could try to catch the error (for me it > was the [file mkdir tcllib1.8] that failed first) rather than just erro= r > out completely. I am not sure here. The tcllib1.8 directory is important for all packages. Erroring out does make sense IMHO. > Next, I'd like to ask where the log ends up (when running the GUI > version). Nowhere. It is only shown in the GUI, but not written to file. > I got some curious error messages in the documentation-making-phase (fo= r > snit_faq, I think), which however didn't stop the installation. Actually warnings. Some of the section/subsection titles are not unique. > I > thought I > could come back to it later, but after installation was complete wish j= ust > exited, and then the information in the log window was no more. (I thin= k > the error said something about a particular string not being a > valid return > code in the sv_se locale (???).) Eh ?? Interesting. [Later, after having browsed the > installer.tcl code a couple of times, I see that the installer indeed j= ust > quits when done. When working in GUI mode, it should first ask the user > whether (s)he wants to save the log window contents. An additional > alternative could be to dump the log window contents to stdout, though.= ] The installer can be forced into non-gui mode, using -no-gui. In that mod= e the log goes to stdout and can be captured. > Another curious thing is the default locations the installer > selects, which > had me confused for quite a while. In my system it wants to place > things in > /System/Library, despite /Library being more appropriate (e.g. being wh= ere > my wish is located). The logic that appears to be responsible for this = is > that libpath is set to the last element of tcl_pkgPath, but is that > appropriate? Looking at how my tcl_pkgPath is constructed, it mostly go= es > from specific (e.g. user-installed packages) to general (those provided= by > the OS vendor), so the things I install should rather go into some of t= he > early entries on this path. Hm. This might actually be platform dependent. From your paths I see that you are on OS X. I tested this so far only on other Unix installations (Linux, Solaris, ...) and Windows. For these the path chosen is quite sensible. > Slightly related, but not having any ill effects for me, is the way in > which the test for a starkit is being performed. It tests whether [info > nameofexecutable] is a prefix of [info library], but it appears to me a= s > the test may miss some cases where this happens. The reason is that I f= ind > my [info nameofexecutable] is the non-normalized > /usr/bin/../../Library/Frameworks/Tk.framework/Versions/8.4/Resources/W= ish > Shell.app/Contents/MacOS/Wish Shell > whereas the [info library] is normalized to > /Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts > Perhaps starkits don't normalize their library paths, or perhaps they d= o, > but one should anyway take note of this possibility for errors. I have to admit, that is the first time that I am seeing a non-normalized path in [info nameofexecutable] ... Ok, Jeff told that this can occur on other Unices as well, symbolic path, or running ./tclsh etc. ... Hm, I gu= ess we should normalize, if [file normalize] is present (remmber, parts of tcllib can be used with 8.2 and 8.3 as well, so the installer cannot assu= me 8.4 features) > Not much actual testing got done, but OTOH these delayed remarks could = be > useful in a slightly longer timeframe. Yes. Definitely. > Lars Hellstr=F6m, > now safely home (after far too many hours waiting in airports > this weekend; I can feel your pain ... My end-of-the-yar vacation is coming up ... Vancouver - Amsterdam - Duesseldorf. Well, better than older flights to various conferences, via Chicago ... That was usually a pain. Today likel= y even more with US border paranoia way up. > aarrrrgh) -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com, a division of Sophos Tel: +1 604 484 6491 |
|
From: Lars <lar...@re...> - 2005-10-12 13:55:26
|
At 21.05 +0200 2005-10-10, Andreas Kupries wrote: >> >> so why not do some whirling, indeed? So >> far I've mostly been dealing with the installer, but I thought I'd better >> start typing things down before I forget... >> >> A first problem I had was that the installer doesn't handle permissions. > >Do you mean by that the installer gets confused by permissions when running= , >or that it does not set permissions on the files it installs ? Primarily the former, but the latter would be good too. >> I understand it probably can't, but there could be some advice in >INSTALL.txt >> on how to deal with this. > >We do have commands in Tcl for this, see "file attributes". Oh, it's unusually inlined. Good! (Although practically it still wouldn't have worked, as my designated target area was originally root-only writable.) >We will have to >distinguish Windows and Unix, but otherwise we could set permissions. We >should possibly discuss what would be good permissions. > > >> Also it could try to catch the error (for me it >> was the [file mkdir tcllib1.8] that failed first) rather than just error >> out completely. > >I am not sure here. The tcllib1.8 directory is important for all packages. >Erroring out does make sense IMHO. I meant "catch in order to provide a more readable error message". In particular if you're running in GUI mode, erroring out looks like an error in the installer rather than an error in the use of it. >> Next, I'd like to ask where the log ends up (when running the GUI >> version). > >Nowhere. It is only shown in the GUI, but not written to file. > >> I got some curious error messages in the documentation-making-phase (for >> snit_faq, I think), which however didn't stop the installation. > >Actually warnings. Some of the section/subsection titles are not unique. > >> I >> thought I >> could come back to it later, but after installation was complete wish jus= t >> exited, and then the information in the log window was no more. (I think >> the error said something about a particular string not being a >> valid return >> code in the sv_se locale (???).) > >Eh ?? Interesting. I thought so too. Copying the message does not appear possible either (text widget bug, or just poor integration with system clipboard?), but retyping it in this mail as it was appearing on screen it turned out to be: Manpage warning (sectambig): unknown error code "sectambig" (for locale sv_s= e). > > [Later, after having browsed the >> installer.tcl code a couple of times, I see that the installer indeed jus= t >> quits when done. When working in GUI mode, it should first ask the user >> whether (s)he wants to save the log window contents. An additional >> alternative could be to dump the log window contents to stdout, though.] > >The installer can be forced into non-gui mode, using -no-gui. In that mode >the log goes to stdout and can be captured. Yeah, but then I'd have to specify a _very_ large number of command line switches to get the locations right. I actually rather _prefer_ the GUI mode. > >> Another curious thing is the default locations the installer >> selects, which >> had me confused for quite a while. In my system it wants to place >> things in >> /System/Library, despite /Library being more appropriate (e.g. being wher= e >> my wish is located). The logic that appears to be responsible for this is >> that libpath is set to the last element of tcl_pkgPath, but is that >> appropriate? Looking at how my tcl_pkgPath is constructed, it mostly goes >> from specific (e.g. user-installed packages) to general (those provided b= y >> the OS vendor), so the things I install should rather go into some of the >> early entries on this path. > >Hm. This might actually be platform dependent. Almost surely the locations are, but wouldn't the search order "user, local additions, vendor distribution" (which might be what in regular Unix? Perhaps ~, /opt, /usr) be logical also on other systems? >From your paths I see that >you are on OS X. I tested this so far only on other Unix installations >(Linux, Solaris, ...) and Windows. For these the path chosen is quite >sensible. Could this be because there isn't much to choose from? Checking the Tcl on a local Linux machine, I find it is just /usr/lib (1 element, so the last is also the first), whereas I here have as [join $tcl_pkgPath \n]: /Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts ~/Library/Tcl /Library/Tcl /Network/Library/Tcl /System/Library/Tcl ~/Library/Frameworks /Library/Frameworks /Network/Library/Frameworks /System/Library/Frameworks Lars Hellstr=F6m |
|
From: Andreas K. <and...@Ac...> - 2005-10-12 17:03:51
|
> At 21.05 +0200 2005-10-10, Andreas Kupries wrote: > >> > >> so why not do some whirling, indeed? So > >> far I've mostly been dealing with the installer, but I thought I'd better > >> start typing things down before I forget... > >> > >> A first problem I had was that the installer doesn't handle permissions. > > > >Do you mean by that the installer gets confused by permissions when running, > >or that it does not set permissions on the files it installs ? > > Primarily the former, but the latter would be good too. Ok. Tcllib tracker, Bug or RFE report please. > >> I understand it probably can't, but there could be some advice in INSTALL.txt > >> on how to deal with this. > > > >We do have commands in Tcl for this, see "file attributes". > > Oh, it's unusually inlined. Good! (Although practically it still wouldn't > have worked, as my designated target area was originally root-only > writable.) Heh. > >> Also it could try to catch the error (for me it > >> was the [file mkdir tcllib1.8] that failed first) rather than just error > >> out completely. > > > >I am not sure here. The tcllib1.8 directory is important for all > packages. > >Erroring out does make sense IMHO. > > I meant "catch in order to provide a more readable error message". Ah, ok. Thanks for the clarification. > In > particular if you're running in GUI mode, erroring out looks like an error > in the installer rather than an error in the use of it. Very good point. Tcllib tracker, Bug report please. > >Actually warnings. Some of the section/subsection titles are not unique. > > > > > >Eh ?? Interesting. > > I thought so too. Copying the message does not appear possible > either (text > widget bug, or just poor integration with system clipboard?), but retyping > it in this mail as it was appearing on screen it turned out to be: > > Manpage warning (sectambig): unknown error code "sectambig" (for > locale sv_se). Ok. This a problem of doctools. It uses message catalogs for the error messages, and did not find a catalog for your locale. I will have to re-read manpages to see if there is a way to fall back into a default locale if the actual one is not found. The code tries to tell about the non-unique (sub)section titles, and then finds that there is no message, and then reports that. Tcllib tracker, Bug report please. > > > > [Later, after having browsed the > >> installer.tcl code a couple of times, I see that the installer > indeed just > >> quits when done. When working in GUI mode, it should first ask the user > >> whether (s)he wants to save the log window contents. An additional > >> alternative could be to dump the log window contents to > stdout, though.] > > > >The installer can be forced into non-gui mode, using -no-gui. In > that mode > >the log goes to stdout and can be captured. > > Yeah, but then I'd have to specify a _very_ large number of command line > switches to get the locations right. I actually rather _prefer_ the GUI > mode. Ok. Tcllib tracker, RFE reports please, for 'have user exit GUI explictly', and 'add button to write accumulated log into a file'. > > > >Hm. This might actually be platform dependent. > > Almost surely the locations are, but wouldn't the search order > "user, local > additions, vendor distribution" (which might be what in regular Unix? > Perhaps ~, /opt, /usr) be logical also on other systems? Not really. Remember, the order of paths in the tcl_pkgPath, and auto_path does not matter for packages at all, at all. The standard behaviour of tclsh when searching for an unknown package is to read all package indices in all listed directories (and their subdirectories) and then choose the highest version number possible within the constraints given to the 'package require'. So the order is really not relevant. Thus the Tcl core library may very well use different orders on the various platforms. > >From your paths I see that > >you are on OS X. I tested this so far only on other Unix installations > >(Linux, Solaris, ...) and Windows. For these the path chosen is quite > >sensible. > > Could this be because there isn't much to choose from? Checking the Tcl on > a local Linux machine, I find it is just /usr/lib (1 element, so the last > is also the first), Heh. Yes, that is of course also a possible reason why things are easy on the other unix platforms. Only one candidate to look at. Forgot about that actually. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com, a division of Sophos Tel: +1 604 484 6491 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X