With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl library on your system!" message despite the fact that the library is successfully found. I read the message in the archives on this, but a) the workaround didn't seem to work for me (if I understood it correctly) and b) it seemed like 1.0.2 was supposed to fix the problem (but obviously didn't in my case).
hmm ... Can you provide a bit more detail? where have you installed xotcl? from where do you run it? what is the setting of the variable auto_path ( use: puts $auto_path at the beginning your program)?
Uwe
On Monday 12 May 2003 16:35, MichaelL@frogware.com wrote:
With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl library on your system!" message despite the fact that the library is successfully found. I read the message in the archives on this, but a) the workaround didn't seem to work for me (if I understood it correctly) and b) it seemed like 1.0.2 was supposed to fix the problem (but obviously didn't in my case).
I'm using XOTcl under both Tcl 8.4.2 and AOLServer. Here's my Tcl 8.4.2 setup.
$auto_path is {d:/appsdev/tcl/lib/tcl8.4 d:/appsdev/tcl/lib} both before and after
package require XOTcl 1
xotcl is installed under d:/appsdev/tcl/lib/xotcl-1.0.2.
In that dir is a pkgIndex.tcl file with the following:
package ifneeded XOTcl 1.0 [list load [file join $dir win/Release/xotcl1.0.dll] XOTcl]
xotcl1.0.dll is under d:/appsdev/tcl/lib/xotcl-1.0.2/win/Release.
I've also tried placing the dll in the bin directory and adjusting the pkgIndex.tcl file accordingly, but it had the same result.
As I said, the dll does in fact load, and I can use XOTcl (and all of its libraries and samples). The problem is just the message.
Uwe Zdun uwe.zdun@wu-wien.ac.at wrote on 05/12/2003 11:28:52 AM:
hmm ... Can you provide a bit more detail? where have you installed
xotcl?
from where do you run it? what is the setting of the variable auto_path
(
use: puts $auto_path at the beginning your program)?
Uwe
On Monday 12 May 2003 16:35, MichaelL@frogware.com wrote:
With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl library on your system!" message despite the fact that the library is successfully found. I read the message in the archives on this, but a)
the
workaround didn't seem to work for me (if I understood it correctly)
and
b) it seemed like 1.0.2 was supposed to fix the problem (but obviously didn't in my case).
-- Uwe Zdun Department of Information Systems, Vienna University of Economics Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746 zdun@{xotcl,computer,acm}.org, uwe.zdun@wu-wien.ac.at
Looking through this code again, the ::xotcl::lib is not really used in XOTcl's code anymore ... and given the fact that you can create some setup, where something goes wrong in searching for the xotcl lib, I would propose to remove the warning message ... that would require the following patch (for 1.0.3) in generic/predefined.xotcl:
@@ -351,7 +351,7 @@ }
if {![info exists success]} { - puts stderr "Cannot locate the XOTcl library on your system!" - return 0 + #puts stderr "Cannot locate the XOTcl library on your system!" + return }
The thing that happens then, if the lib is not found, is that it is reset to the compiled-in default ... which is ok, I think.
--uwe
On Monday 12 May 2003 19:20, MichaelL@frogware.com wrote:
I'm using XOTcl under both Tcl 8.4.2 and AOLServer. Here's my Tcl 8.4.2 setup.
$auto_path is {d:/appsdev/tcl/lib/tcl8.4 d:/appsdev/tcl/lib} both before and after
package require XOTcl 1xotcl is installed under d:/appsdev/tcl/lib/xotcl-1.0.2.
In that dir is a pkgIndex.tcl file with the following:
package ifneeded XOTcl 1.0 [list load [file join $dirwin/Release/xotcl1.0.dll] XOTcl]
xotcl1.0.dll is under d:/appsdev/tcl/lib/xotcl-1.0.2/win/Release.
I've also tried placing the dll in the bin directory and adjusting the pkgIndex.tcl file accordingly, but it had the same result.
As I said, the dll does in fact load, and I can use XOTcl (and all of its libraries and samples). The problem is just the message.
Uwe Zdun uwe.zdun@wu-wien.ac.at wrote on 05/12/2003 11:28:52 AM:
hmm ... Can you provide a bit more detail? where have you installed
xotcl?
from where do you run it? what is the setting of the variable auto_path
(
use: puts $auto_path at the beginning your program)?
Uwe
On Monday 12 May 2003 16:35, MichaelL@frogware.com wrote:
With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl library on your system!" message despite the fact that the library is successfully found. I read the message in the archives on this, but a)
the
workaround didn't seem to work for me (if I understood it correctly)
and
b) it seemed like 1.0.2 was supposed to fix the problem (but obviously didn't in my case).
-- Uwe Zdun Department of Information Systems, Vienna University of Economics Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746 zdun@{xotcl,computer,acm}.org, uwe.zdun@wu-wien.ac.at
On Monday 12 May 2003 20:04, Uwe Zdun wrote:
Looking through this code again, the ::xotcl::lib is not really used in XOTcl's code anymore ...
hmm? The line after the error message says: set ::auto_path [concat $::xotcl::lib $::auto_path] if the variable is not set, you get the error message there. it is certainly possible to set a default value, say from the configure prefix....
The more sensible change is to use the patch below, which will be ok, when you load xotcl via xotclsh, but will not find xotcl packages, when xotcl is loaded via tclsh; try:
tclsh package require XOTcl namespace import ::xotcl::* package require package
Currenty, xotcl does a patch checking in C (findXOTcl.c) and in tcl (predefined.xotcl). my hope was rather to get rid of the c-code... The background of this code is as follows: - tcl searches the libraries in auto_path and the subdirs of that. - with xotcl i would like the get one more level to organize the xotcl packages more nicely. - therefore the xotcl library is added to the auto_path. We would not need the library, when we assemble a large tclIndex.tcl file in the xotcl directory. Maybe that is the better way... we will check this more carefully...
best regards -gustaf
-- predefined.xotcl~ 2003-04-24 22:49:14.000000000 +0200 +++ predefined.xotcl 2003-05-12 21:48:20.000000000 +0200 @@ -357,12 +357,9 @@ } }
- if {![info exists success]} { - puts stderr "Cannot locate the XOTcl library on your system!" - return 0 + if {[info exists ::xotcl::lib]} { + set ::auto_path [concat $::xotcl::lib $::auto_path] } - #puts stderr "[info exists success] <$::xotcl::lib>" - set ::auto_path [concat $::xotcl::lib $::auto_path]
# # and forget all "xotcl::" packages in Tcl's packageTable so that they
I don't know if this helps, but my approach was to add the following in xotcl-1.0.2/pkgIndex.tcl:
set _dir_ $dir foreach {subdir} { library/actiweb library/comm library/lib library/patterns library/rdf library/registry library/serialize library/store library/xml } { set dir [file join $_dir_ $subdir ] source [file join $dir pkgIndex.tcl] } set dir $_dir_ unset _dir_
This isn't as elegant as it could be--for example, the list of subdirs could obviously be dynamically generated--but it does use the existing package loading mechanism (including the default pkgIndex.tcl files in the subdirs).
Gustaf Neumann neumann@wu-wien.ac.at wrote on 05/12/2003 04:14:52 PM:
The background of this code is as follows:
- tcl searches the libraries in auto_path and the subdirs of that.
- with xotcl i would like the get one more level to organize the xotcl packages more nicely.
- therefore the xotcl library is added to the auto_path.
On Monday 12 May 2003 23:27, MichaelL@frogware.com wrote:
I don't know if this helps, but my approach was to add the following in xotcl-1.0.2/pkgIndex.tcl:
Good idea!
the following is more generic an should work (if it placed into the installed directory of the xotcl library) platform indepently.
We should think a little about what to do to execute xotcl in the noninstalled case (e.g. - putting this into xotcl-$(VERSION)/library, - add a simple pkgIndex.tcl to xotcl-$(VERSION) to load the shared lib - add xotcl-$(VERSION) to auto_path ) and to produce the attached one on install.... This is the way we should go.
-gustaf
============================================================ package ifneeded XOTcl 1.0 [list load \ [file join $dir .. libxotcl1.0[info sharedlibextension]] XOTcl]
set _dir_ $dir foreach index [glob -nocomplain [file join $dir * pkgIndex.tcl]] { set dir [file dirname $index] source $index } set dir $_dir_ unset _dir_ ============================================================
It does not solve the main problems solved by check_library_path: to include the env(XOTcl) variable and use the local directory when you are in it so that you don't necessarily have to install. The rest of the code (in the second else part) is only used to set the xotcl::lib variable correctly. Again: this variable is not really needed. At the moment, it is only an information for the programmer.
we can think about getting rid of the variable, maybe.
--uwe
On Tuesday 13 May 2003 10:50, Gustaf Neumann wrote:
On Monday 12 May 2003 23:27, MichaelL@frogware.com wrote:
I don't know if this helps, but my approach was to add the following in xotcl-1.0.2/pkgIndex.tcl:
Good idea!
the following is more generic an should work (if it placed into the installed directory of the xotcl library) platform indepently.
We should think a little about what to do to execute xotcl in the noninstalled case (e.g.
- putting this into xotcl-$(VERSION)/library,
- add a simple pkgIndex.tcl to xotcl-$(VERSION) to load the shared lib
- add xotcl-$(VERSION) to auto_path
) and to produce the attached one on install.... This is the way we should go.
-gustaf
============================================================ package ifneeded XOTcl 1.0 [list load \ [file join $dir .. libxotcl1.0[info sharedlibextension]] XOTcl]
set _dir_ $dir foreach index [glob -nocomplain [file join $dir * pkgIndex.tcl]] { set dir [file dirname $index] source $index } set dir $_dir_ unset _dir_ ============================================================
On Tuesday 13 May 2003 11:53, Uwe Zdun wrote:
It does not solve the main problems solved by check_library_path: to include the env(XOTcl) variable
true, i think we dont need it
and use the local directory when you are in it so that you don't necessarily have to install.
as stated in my last mail. extending the autopath or tcllibpath should solve this.
The rest of the code (in the second else part) is only used to set the xotcl::lib variable correctly. Again: this variable is not really needed. At the moment, it is only an information for the programmer.
we can think about getting rid of the variable, maybe.
there is code in the xotcl package "package" to determine the name of the library directory. an application needing this info can use this approach...
-gustaf
--uwe
On Tuesday 13 May 2003 10:50, Gustaf Neumann wrote:
On Monday 12 May 2003 23:27, MichaelL@frogware.com wrote:
I don't know if this helps, but my approach was to add the following in xotcl-1.0.2/pkgIndex.tcl:
Good idea!
the following is more generic an should work (if it placed into the installed directory of the xotcl library) platform indepently.
We should think a little about what to do to execute xotcl in the noninstalled case (e.g.
- putting this into xotcl-$(VERSION)/library,
- add a simple pkgIndex.tcl to xotcl-$(VERSION) to load the shared lib
- add xotcl-$(VERSION) to auto_path
) and to produce the attached one on install.... This is the way we should go.
-gustaf
============================================================ package ifneeded XOTcl 1.0 [list load \ [file join $dir .. libxotcl1.0[info sharedlibextension]] XOTcl]
set _dir_ $dir foreach index [glob -nocomplain [file join $dir * pkgIndex.tcl]] { set dir [file dirname $index] source $index } set dir $_dir_ unset _dir_ ============================================================
On Tuesday 13 May 2003 11:49, Gustaf Neumann wrote:
and use the local directory when you are in it so that you don't necessarily have to install.
as stated in my last mail. extending the autopath or tcllibpath should solve this.
and that (extending the autopath) is exactly what the method check_library_path essentially does. I think we can get rid of the part:
foreach d $::auto_path { set xl xotcl$::xotcl::version foreach x [list [file join $d $xl] [file join $d .. $xl]] { #puts stderr "check $x" if {[file isdirectory $x]} { set ::xotcl::lib $x set success 1 break } } if {[info exists success]} {break} }
if we don't want the xotcl::lib variable ... the rest (except the ENV part) is needed somewhere, i think. I guess, if we code these things into the pkgindex files we would need a different version for the Win and unix installation.
there is code in the xotcl package "package" to determine the name of the library directory. an application needing this info can use this approach...
I'm not sure, which method do you mean in package.xotcl??
--uwe
Hi,
I am fairly new to XOTcl and this list, but so far I like XOTcl.. Recently on clt, this was posted regarding tk widgets/framework
----snip--- I haven't looked recently. Tix is technically adequate, I suspect, but there are cleaner ways of doing OO. My vote would be for something based on XOTcl---it seems to have about the best performance of the various OO frameworks, and it feels more like Tcl than (say) [incr Tcl]. On the other hand, [incr Tcl] has a nice set of megawidgets in [incr Widgets], so it's more nearly there.
Is there any thoughts on anything like this from the XOTcl team...
regards,
nicolas
Hi,
you're right, there is no mega-widget packet for XOTcl (I often use Tcl megawidgets such as Bwidgets) ... yet it is quite simple to integrate Tk and XOTcl; and build you're own megawidgets. I found that wrapping the simple Tk widgets (or Bwidgets) does not make too much sense, but building classes that represent more complex GUI elements is very useful. The most simple thing you can do is to store the widget IDs of the associated widget in a variable on the object representing it.
As said before, I do not use an integration <one widget == one object> anymore but let the objects aggregate more than one widget. As for instance a class TextEditor that contains a ScrolledWindow, a ctext, and some buttons.
I often integrate the name of the object and the name of the top widget in such composite widgets. Here you have to be careful, the object name returned by [self] contains "::" which you have to strip. Also object names can potentially start with an upper case letter, widget IDs not. I only use lower cases object names, so I can do something like:
button .[namespace tail [self]]
in the constructor. Or you replace the "::"'s with "."'s, if you want to use XOTcl aggregation to model a class hierarchy.
Another issue is callback commands. You usually want them to be dispatched on the object. Then you cannot do something like:
button .[namespace tail [self]] -command {[self] doSometing}
as the self is replaced in the wrong scope (of the callback) (because of the brackets: {}) and does not find the object. Instead you have to use substitution:
button .[namespace tail [self]] -command [list [self] doSometing]
If you want to see some nice larger examples, download XOTclIDE (www.xdobry.de/xotclIDE) and look at the file IDEBaseGUI.xotcl ...
Uwe
On Thursday 15 May 2003 08:09, Nicolas Boretos wrote:
Hi,
I am fairly new to XOTcl and this list, but so far I like XOTcl.. Recently on clt, this was posted regarding tk widgets/framework
----snip--- I haven't looked recently. Tix is technically adequate, I suspect, but there are cleaner ways of doing OO. My vote would be for something based on XOTcl---it seems to have about the best performance of the various OO frameworks, and it feels more like Tcl than (say) [incr Tcl]. On the other hand, [incr Tcl] has a nice set of megawidgets in [incr Widgets], so it's more nearly there.
Is there any thoughts on anything like this from the XOTcl team...
regards,
nicolas
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
Hello again,
We are at the onset of a Web based project to be built on, at least the current thinking is, on XML/SOAP. Basically, a Web browser interface calling SOAP methods on a SOAP server. Initial trials using tcl soap along with the the package's SOAP::domain stuff under tclhttpd seem promising, if possibly a bit cludgey and slow...We also work with Aolserver, but have not looked at ns_soap..
Most of the application are requests for Eurosta data (living in a postgres db), calculations, and generating charts, pies, graphs, XML reports etc.
I was wondering as to what efforts, if any are being done along these lines. I found some tclhttpd/soap etc wrappings on Mr. Zdun's site, but could not really get these to work (cleanly, at least). I also found the link below but have not
http://nm.wu-wien.ac.at/Lehre/oo2/04-39.html
had a chance to look at it.
Is there anything newer/other along these lines available? Most of our thinking is to eventually move towards your ActiWeb/Active Web Objects, but we are still in the exploration phase. I also have a gut feeling that tis project will grow/change as time goes, which infers maintainability issues, which is why we are shying away from our intial tcl/tclsoap approach and more towards XOTcl/objects....
regards,
nicolas boretos
Hi, to give you a short answer: we have currently no special soap support from xotcl. Uwe has started some work some time ago, i started from his work to use it for teaching purposes, but it is by no means a general SOAP support. The way we should go is to use tDOM as a basis and build a reasoable support on top of it. It is not particularly hard, but requires certainly some work (this looks like a fun project to me, working towards automatic generated WSDL descriptions from some meta-data).
If you are on a project time-line, i would recommend to use XML-RPC if this is an option for you. I can send you some xotcl-code based on tDOM as starting point, if you are interested...
best regards -gustaf neumann
The SOAP integration on my homepage is a simple example how to integrate TclSOAP (with tclhttpd ... it should be no problem to use another web server) and XOTcl. This is not intended as production code ... I prepared it for a student project. It worked for the students (they have done a web calendar with it). Yet, it can only handle generic invocations and more work would to be done to provide a more complete integration. The disadvantage of this solution is that TclSOAP is not the fastest variant ... I don't know in how far that matters compared to other web service solutions, web services are slow anyway.
two other solutions are possible, writing a new SOAP implementation (as Gustaf suggested e.g. with tdom) ... that's a lot of work ... the word "simple" in SOAP should not be taken literaly.
or you integrate an existing solution in another language in Tcl or Tcl in it respectively.
--uwe
On Thursday 15 May 2003 11:17, Nicolas Boretos wrote:
Hello again,
We are at the onset of a Web based project to be built on, at least the current thinking is, on XML/SOAP. Basically, a Web browser interface calling SOAP methods on a SOAP server. Initial trials using tcl soap along with the the package's SOAP::domain stuff under tclhttpd seem promising, if possibly a bit cludgey and slow...We also work with Aolserver, but have not looked at ns_soap..
Most of the application are requests for Eurosta data (living in a postgres db), calculations, and generating charts, pies, graphs, XML reports etc.
I was wondering as to what efforts, if any are being done along these lines. I found some tclhttpd/soap etc wrappings on Mr. Zdun's site, but could not really get these to work (cleanly, at least). I also found the link below but have not
http://nm.wu-wien.ac.at/Lehre/oo2/04-39.html
had a chance to look at it.
Is there anything newer/other along these lines available? Most of our thinking is to eventually move towards your ActiWeb/Active Web Objects, but we are still in the exploration phase. I also have a gut feeling that tis project will grow/change as time goes, which infers maintainability issues, which is why we are shying away from our intial tcl/tclsoap approach and more towards XOTcl/objects....
regards,
nicolas boretos
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
On Thu, 15 May 2003, Uwe Zdun wrote:
you're right, there is no mega-widget packet for XOTcl (I often use Tcl megawidgets such as Bwidgets) ... yet it is quite simple to integrate Tk and XOTcl; and build you're own megawidgets. I found that wrapping the simple Tk widgets (or Bwidgets) does not make too much sense, but building classes that represent more complex GUI elements is very useful. The most simple thing you can do is to store the widget IDs of the associated widget in a variable on the object representing it.
I have a small bunch of classes and methods that makes using Tk with XOTcl a good bit easier (IMO, of course). If I remember later I can stick them up somewhere. Just remind me :-)
(Have to go to a meeting soon)
maybe, what you have overlooked in my patch was that there is a "return" in:
if {![info exists success]} { #puts stderr "Cannot locate the XOTcl library on your system!" return }
BTW, ::xotcl::lib is always set at this point. Before the method "check_library_path", xotcl.c sets it to the compiled-in default. the auto_path should only be changed if we learn in check_library_path that we want to change it (and not to the compiled-in default). The code below does not work, because you use the wrong package name:
% package require XOTcl 1.0 % namespace import ::xotcl::* % package require package can't find package package % package require xotcl::package 0.91
the C findXOTcl searches for the xotcl .so/.dll and is not related to the "check_library_path" method. Its only used in the xotclAppInit.c fake shell, not in xotcl.c
I would still propose the patch from yesterday.
--uwe
On Monday 12 May 2003 22:14, Gustaf Neumann wrote:
On Monday 12 May 2003 20:04, Uwe Zdun wrote:
Looking through this code again, the ::xotcl::lib is not really used in XOTcl's code anymore ...
hmm? The line after the error message says: set ::auto_path [concat $::xotcl::lib $::auto_path] if the variable is not set, you get the error message there. it is certainly possible to set a default value, say from the configure prefix....
The more sensible change is to use the patch below, which will be ok, when you load xotcl via xotclsh, but will not find xotcl packages, when xotcl is loaded via tclsh; try:
tclsh package require XOTcl namespace import ::xotcl::* package require package
Currenty, xotcl does a patch checking in C (findXOTcl.c) and in tcl (predefined.xotcl). my hope was rather to get rid of the c-code... The background of this code is as follows:
- tcl searches the libraries in auto_path and the subdirs of that.
- with xotcl i would like the get one more level to organize the xotcl packages more nicely.
- therefore the xotcl library is added to the auto_path.
We would not need the library, when we assemble a large tclIndex.tcl file in the xotcl directory. Maybe that is the better way... we will check this more carefully...
best regards -gustaf
-- predefined.xotcl~ 2003-04-24 22:49:14.000000000 +0200 +++ predefined.xotcl 2003-05-12 21:48:20.000000000 +0200 @@ -357,12 +357,9 @@ } }
- if {![info exists success]} {
puts stderr "Cannot locate the XOTcl library on your system!"return 0
- if {[info exists ::xotcl::lib]} {
set ::auto_path [concat $::xotcl::lib $::auto_path]
#puts stderr "[info exists success] <$::xotcl::lib>"
set ::auto_path [concat $::xotcl::lib $::auto_path]
# # and forget all "xotcl::" packages in Tcl's packageTable so that they
-
Gustaf Neumann -
Kristoffer Lawson -
MichaelL＠frogware.com -
Nicolas Boretos -
Uwe Zdun