>  Dear Jeff,
>  
>  Thank you very much for your reply. I am quite puzzled about this.
>  I did a "teacup update-self" & "teacup update" today, before re-wrapping 
>  my app.
>   From my app, I have removed a copy of tablelist, tclodbc & tktable I 
>  had inside my application (in order to use the standard packages from 
>  the 8.5 teapot repository). I re-wrapped my application, but today I 
>  cannot get it to reproduce the problem
>  I had with excel. But I didn't see "teacup update" updating anything 
>  related :-(
>  
>  So, the only problem I now have is with the tablelist_tile package, 
>  which does not work unless I do:
>  
>  catch {package require tablelist_tile}
>  package require Tablelist_tile

 
>  For some reason "package require tablelist_tile" fails when the app is 
>  ran unwrapped,
>  and "package require Tablelist_tile" fails unless I do a "package 
>  require tablelist_tile" before when wrapped.
>  (doing only "package require tablelist_tile" when wrapped gives errors 
>  when using the package. Doing both works ok.)


I believe you are running into the difference of filesystems native vs. metakit (wrapped), a
nd a bad interaction how we generate the packages in the teapot. Metakit is a unix filesyste
m, it stores case and use lettercase when searching for a file. Windows, while storing case 
doesn't use it for searching.

Tablelist is a grrk example of what can happen.

One, the file tablelist_tile declares itself to provide two packages, tablelist_table, and t
he Tablelist_tile, with the uppercase T.

When we put this into the TEApot it is seen by our generator as a Tcl Module (because it is 
a single file pure Tcl), and the generator creates two files, one for each provided package 
name,

	Tablelist_tile-X.y.tm
	tablelist_tile-X.y.tm

Can you see where this is going ?

When you have both packages in your repository Windows overwrites one of the files with the 
other, because to it the file names are not different.

I am thinking that you have the 'tablelist_tile' form stored. When Tablelist_tile is now sea
rched unwrapped it works, TMs are specified to use case-insensitive search. However when Tcl
App wraps it it is again 'tabelist_tile' and so noted in the generated pkgIndex.tcl (*). now
, as a package it will be found only under this name. After it has been loaded it has also d
eclared the other name, and so that is then found found as well. That explains why your catc
h/require sequence works. 

(*) TclApp converts TM to regular packages for wrapping, it cannot be sure that the runtime 
supports TMs.


Fixes ... Difficult ...

(1) Use zip file and regular package instead of TMs ?
    Doesn't work. Now they will be stored in the same directory.

    While we can overwrite files I do not think that we can do
    the same for directories. I.e. with this we may cause errors
    during 'teacup install'.

(2)	Use zip file, keep original pkgIndex.tcl ... Now we have
	a 3-in-1 package, i.e. one teabag with a single package name
	to the outside, but the code contains three packages, and
	with the 2 aliases it can be said to contain 5, and all are
	accessible to 'package require'. This seems to be a viable
	solution on first glance, however I haven't fully thought
	through what other parts of the system this could break.

(3)	Declare one of the spellings the official one, and put only
	the packages for this spelling into the teapot.

	Then use only that spelling in the code as well.

	With the way TclApp converts TMs to regular packages this would
	have to the full lower-case name, I think.

I have now cc'd Csaba, author of Tablelist..., see what his take on this is.


I see that we recently (this weekend) went to version 4.9.2. I will delay putting anything f
or that version into the teapot, that should give us time to make a decision on how to go fo
rward.


With a quick check ... currently it is only tablelist(_tile) affected by this.
The wcb/Wcb package would have been affected as well, except that building them is currently
 broken it seems, and fixing a low priority.






>  The problem is that I cannot reproduce any more the failure with excel 
>  when wrapped. But I didn't changed anything.
>  And still, the executables I had built before do still have the problem 
>  when interacting with excel.
>  So, I don;t have the problem any more, but also I haven't found the 
>  cause for the failure I had (which was reproducable in at least 3 
>  different PCs).
>  
>  Best regards,
>  
>  George
>  
>  O/H Jeff Hobbs έγραÏ?ε:
>  > Hi George,
>  >
>  > George Petasis wrote:
>  >> I am facing a problem with TDK 4.1.0, which I don't know how to debug.
>  >> I have a medium-sized application in Tcl, with a few C extensions
>  >> (through SWIG).
>  >
>  > Are you sure that all your SWIG apps are (1) built with stubs and (2) 
>  > 8.5 compatible (no internal Tcl access)?
>  >
>  >> The applications runs ok from the disk (unwrapped). Among other stuff,
>  >> it interacts with excel, and writes a spreadsheet.
>  > [wrapped with 8.5 basekit presumably]
>  >> BUT, the exe I get exhibits a slightly different behaviour: it 
>  is unable
>  >> to write the excel spreadsheet for some (but not all)
>  >> excel spreadsheets. So, something is different between the wrapped &
>  >> unwrapped applications. How can I find out what is different?
>  >
>  > Beyond the encoding issue mentioned, are you certain that when run 
>  > unwrapped, it is using the same versions of libraries and core?
>  >
>  >> So, I tried to change the way I create the wrapped app, and decided to
>  >> use the tclapp GUI to do the wrapping. But with no success :-) What I
>  >> did was:
>  > ...
>  >> I wrapped my app, but not it fails finding a package:
>  >>
>  >> can't find package Tablelist_tile
>  >> while executing
>  >> "package require Tablelist_tile"
>  >
>  > This may be a missing dependency on Tablelist package usage, and a 
>  > separate issue.
>  >
>  >> During wrapping of course, the package was there:
>  > ...
>  >> BTW, my app works as a wrapped one with 8.4 & TDK 3.x. Including
>  >> writting the excel spreadsheet for the files
>  >> that now fails. How to debug this?
>  >
>  > What if you use 8.4 with TDK 4? I suspect it is more likely an 8.4/8.5 
>  > variation rather than TDK 3/4, but I want to be sure.
>  >
>  > Regards,
>  >
>  > Jeff
>  >
>  
>  
>  _______________________________________________
>  TDK mailing list
>  TDK@[...].com
>  http://listserv.ActiveState.com/mailman/listinfo/tdk
>  


--
	Andreas Kupries <andreask@[...].com> 
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

_______________________________________________
TDK mailing list
TDK@[...].com
http://listserv.ActiveState.com/mailman/listinfo/tdk