View · Search · Index
No registered users in community xowiki
in last 10 minutes

Weblog Page

Showing 421 - 430 of 1561 Postings (summary)

[Xotcl] XotclIDE Version 0.22

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Artur Trzewik <mail_at_xdobry.de>
Date: Tue, 6 Nov 2001 20:58:05 +0100

Hi!

New Version of XotclIDE is available

http://www.xdobry.de/xotclide

Changes:
1. Support Documentation. Every component, class or method can be commented.
The comments are saved in version control system or as standard _at_ xotclide
tokens. XotclIDE can also read _at_ tokens.
2. Installation Tool for Version Control. A GUI to specify connection
parameter to mysql, installing tables and components in repository.
program - installVC
3. Database connection parameters can be specified in configuration file
.xotclide
4. Another small changes and bug cleaning.

Future development:
I have got some wishes to xotclIDE from another people.
1. Tutorial
2. Tools and documentation: how to convert xotcl project to xotclIDE
3. support for tcl (functions, normal procs)
4. support for xemacs
5. support for cvs

I have also thought about a converter tool itcl2xotcl.
It were nice to convert Iwidgets to xotcl.
Unfortunately itcl have very weak introspection functionality so after some
hours of itcl-learning I have given up.
If some body know the way how to recreate itcl classes from interpreter or
have more itcl know-how please let me now it.

For xotclIDE I plan to build a simple interactive tutorial.
For another extensions (see above) I have no ideas.
My really problem of the future development is debugging.
Unfortunately tcl was designed for short scripts. What I miss is:
1. no access to parse tree.
2. in error case the error stack is discarted. So after error you must restart
the program flow.
3. Interpreter do not support access to internall program flow. The step
function in debugger is not possible.
I have read in tcl news groups that also another people have thought about it.
Perhaps new tcl version can it.
It is too big thing to make it without tcl core team.

have fun
Artur Trzewik

[Xotcl] XOTclIDE in Version 0.57

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 10 Jan 2004 17:32:52 +0100

Hi!

New Version of XOTclIDE 0.57 is released.
http://www.xdobry.de/xotclIDE

changes:
- Additional editior functions
 - minus indent, plus indent, auto indent region
 - comment and uncomment region
- New plug-ins:
 - tk windows inpector - can show tk windows hierarchy.
       view and change widget configuration.
       serialize widgets trees to tcl script
 - script editor - enable syntax checker and command completion
       also for small tcl scripts
- more panned windows (when you use Tcl8.4)
- startpacks for windows and linux with updated atkdebugger (version 0.21)
  and Tcl8.4.5
  http://www.xdobry.de/xotclIDE/xotclide_win.html
  This binaries includes ready to use extended debugger.
- sqlite connection dialog use file dialog to get sqllite file
- this version is prepared and also tested with pre-release of XOTcl 1.1.2
  that Gustav Neuman give me for testing.
  Warning! Old XOTclIDE releases would not work reliable with XOTcl 1.1.2
- many refactoring and bug fixies (see Change Log) and small improvements
  in gui handling.

I have some problems with XOTcl 1.1.1 by using debugger.
Please use XOTcl 1.0.2 if you should work with extended debugger.

Artur Trzewik

[Xotcl] Calling object

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 9 Jul 2010 17:11:10 +0300

While XOTcl has a way to ask to query the object that is calling the current procedure, there does not seem to be a way to find out which object was 'previous' on the stack. I'll illustrate:

Class C

C instproc hello {} {
        puts "Hello, [self callingobject]"
}

C instproc do {} {
        my hello
}


Now if I call [hello] from another object, I will get the object which called [hello]. Of course, if that object calls [do] instead of [hello], then [self callingobject] will end up being the same as [self]. [uplevel] doesn't help here as [self callingobject] will always return the same, whatever stack level I call it from (is this a bug or intentional?). Basically there is no way to check "caller of caller" or, indeed, the "original caller" — ie. the object before [self] which initiated the process.

The reason I want to do this is that I have an access control system which calls something like [checkPermissions]. [checkPermissions] should just return and do nothing if the original calling object is equal to [self]. Now I end up having to passs [checkPermissions] a parameter with [self callingobject].

I guess I could also do this with a filter but that might be overkill for something so simple.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

Re: [Xotcl] error with slots?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Wed, 09 Jun 2010 15:26:29 +0200

salut!

> Any help is greatly appreciated.

The line

>> Attribute options Default ""

should read

> Attribute options -default ""

why ...

>> The code has been working for about 2 years without giving any error

i can't explain right now (and i don't have the time to take a closer
look), i can only state that it shouldn't have, in the end. without
correctly specifying the default value, the string items 'Default ""'
are passed to the application-level "constructor", i.e. Sim->init(). as
init does not accept any arguments, you run into the error condition
reported.

bien à toi

//stefan

[Xotcl] error not taken in account in init instproc

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Fabrice Pardo <Fabrice.Pardo_at_Lpn.cnrs.fr>
Date: Wed, 23 Feb 2005 12:16:39 +0100 (MET)

The errors seems not to be taken in account in "init" instproc:

Class create C
C instproc init {e} {
    if {$e} {error "an error"}
    next
}
C create o1 1 ;# ::o1
set errorInfo ;# an error...while executing...
C create o1 1 ;# now a blank line !
C create o2 ;# ::o2
set errorInfo ;# wrong # args: should be "init e" ...

# Program version:
info patchlevel ;# 8.4.8
package ifneeded XOTcl 1.3.3 ;# load /.../libxotcl1.3.3.so XOTcl

-- 
Fabrice Pardo

[Xotcl] Re: Bug: configure step chooses wrong tclsh [REASONING]

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Apr 2004 21:01:53 +0200

On Friday 09 April 2004 16:04, Jim Lynch wrote:
> Hi,
>
> I've been talking to people on the irc channel, Jeff Hobbs among them,
> about the tclsh issue. Jeff's contention, as far as I understand it, is
> that if tclsh is not used to actually load the extension it's building,
> any tclsh will do, and that the TEA_PROG_TCLSH macro uses a more correct
> ordering to find tclsh: so long as the supplied tclConfig.sh refers to
> its tclsh, that tclsh ought to be found first.

 I was not on the chat, but:

   - Jeffs suggestion was to use the TEA_* macros instead of the
     stuff we use currently. I was not aware of these new TEA macros.
     the sample extension (sampleextension-0.2) in http://www.tcl.tk/doc/tea/
     contains only SC_* macros, and no TEA_ at all. the same is with tcl8.4.6
        find tcl8.4.6 -type f | xargs fgrep TEA_
     On the other hadm it still uses SC_PROG_TCLSH, determined by
        find tcl8.4.6 -type f | xargs fgrep PROG_TCLSH

     By googling around, i found
     http://cvs.sourceforge.net/viewcvs.py/tcl/sampleextension/configure.in?rev=1.37
     which is quite different from the macros.

     so... i come to think that SC_PROG_TCLSH is currently the way to go,
     but TEA2 will at some time do everything better with new TEA_* macros
     
  - It is not arbitray, which PROG_TCLSH is used for xotcl:
    Since xotcl depends on some tclInt.h structures, which change from time
    to time, it is highly recommend to use a tclsh, which was compiled with the
    same tclInt.h as the xotcl extension (except you use the xotlc shells, which
    is deprecated). Mixing shells is as well a problem if you use theads e.g.
    for xotcl.
 
 on my fedora system i have tcl and xotcl in the same directory, configure
 finds the source version and places e.g.
     TCLSH_PROG = /home/neumann/tcl8.4.6/unix/tclsh
 to the Makefile. is this on your system different?

 -gustaf neumann
>
> Among other things, I'm now trying to determine whether the build process
> of xotcl actually needs that specific tclsh or not; right now my guess
> is that it does.
>
> -Jim
>
> --
> Jam sessions community web site: http://jam.sessionsnet.org
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

Re: [Xotcl] Compiling NX fails

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Victor Mayevski <vitick_at_gmail.com>
Date: Mon, 21 Mar 2011 08:16:15 -0700

Thanks Gustaf, it works now.

On Mon, Mar 21, 2011 at 4:02 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
> Hi Victor,
>
> a head version is always a moving target. This time, essentially the type
> TEOV_callback was renamed to NRE_callback. Unfortunately, there are no
> different version numbers available to the preprocessor, so i appended the
> changes to NRE_SANE_PATCH. Please use it for working against Tcl-head.

Not sure if I had to do anything extra here, since NX compiled just
fine without me changing anything.

>
> The updated version in git compiles now nicely and runs all regression tests
> except the coro-test. Inside a coroutine, we get now a crash, the stack
> frame with the variables is apparently missing. I have deactivated the
> coro-test for the time being.
>
> In order to address the problem i have to learn how to master tcl + fossil
> at a higher level. First, i tried to get the Tcl via fossil. "fossil clone
>  http://core.tcl.tk/tcl" runs now since a few hours and hangs now... It has
> already transfered 58MB; however, since there is no progress, I have killed
> it and restarted it again, maybe it works in the new few hours.

It was suggested to use mirror1.tcl.tk because core.tcl.tk has limited
bandwidth. The instructions are here: http://wiki.tcl.tk/28126

>
> I got a snapshot version via
>   wget http://core.tcl.tk/tcl/zip/Tcl.zip?uuid=trunk
> If someone knows if it is possible to specify a date for the wget above,
> please let me know, this would ease to locate the changes that are causing
> now problems.
>
> -gustaf neumann
>
> On 21.03.11 04:09, Victor Mayevski wrote:
>>
>> Hello Gustaf,
>>
>> I have switched the TCL repository from SourceForge to Fossil, got the
>> latest sources, compiled and installed TCL. The problem now is that NX
>> will not compile against it.
>> Make fails with this error:
>>
>>
>> ########################################################################################
>> gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
>> -DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
>> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
>> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
>> -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
>> -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
>> -DMODULE_SCOPE=extern\
>> __attribute__\(\(__visibility__\(\"hidden\"\)\)\)
>> -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
>> -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
>> -DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
>> -DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
>> -I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
>> -I./generic    -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC  -c
>> `echo ./generic/nsf.c` -o nsf.o
>> ./generic/nsf.c: In function ‘MethodDispatchCsc’:
>> ./generic/nsf.c:7797: error: ‘TEOV_callback’ undeclared (first use in
>> this function)
>> ./generic/nsf.c:7797: error: (Each undeclared identifier is reported only
>> once
>> ./generic/nsf.c:7797: error: for each function it appears in.)
>> ./generic/nsf.c:7797: error: ‘rootPtr’ undeclared (first use in this
>> function)
>> ./generic/nsf.c: In function ‘DispatchDestroyMethod’:
>> ./generic/nsf.c:8503: warning: too many arguments for format
>> make: *** [nsf.o] Error 1
>>
>> ###################################################################################
>>
>>
>>
>> If I uncomment "#define NRE_SANE_PATCH 1", as I had to do every time I
>> compiled NX, the error is even longer, I will just give the first few
>> lines:
>>
>>
>> ###################################################################################
>>
>> gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
>> -DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
>> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
>> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
>> -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
>> -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
>> -DMODULE_SCOPE=extern\
>> __attribute__\(\(__visibility__\(\"hidden\"\)\)\)
>> -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
>> -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
>> -DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
>> -DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
>> -I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
>> -I./generic    -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC  -c
>> `echo ./generic/nsf.c` -o nsf.o
>> In file included from ./generic/nsf.c:45:
>> ./generic/nsfInt.h:725: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>> ‘__attribute__’ before ‘NRE_SANE_PATCH’
>> ./generic/nsfInt.h:792: warning: data definition has no type or storage
>> class
>> ./generic/nsfInt.h:792: warning: type defaults to ‘int’ in declaration
>> of ‘NsfRuntimeState’
>> ./generic/nsf.c: In function ‘NsfLog’:
>> ./generic/nsf.c:362: error: expected expression before ‘)’ token
>> In file included from ./generic/nsf.c:629:
>> ./generic/nsfStack.c: In function ‘CscListAdd’:
>> ./generic/nsfStack.c:21: error: expected expression before ‘)’ token
>> ./generic/nsfStack.c: In function ‘CscListRemove’:
>> ./generic/nsfStack.c:42: error: expected expression before ‘)’ token
>> ./generic/nsfStack.c: In function ‘Nsf_PushFrameObj’:
>> ./generic/nsfStack.c:144: error: expected expression before ‘)’ token
>> ./generic/nsfStack.c: In function ‘Nsf_PushFrameCsc’:
>> ./generic/nsfStack.c:187: error: expected expression before ‘)’ token
>> ./generic/nsfStack.c: In function ‘CallStackPopAll’:
>>
>> ########################################################################################
>>
>> I am on Debian based Linux, 32bit.
>>
>> Thanks,
>>
>> Victor
>>
>> _______________________________________________
>> Xotcl mailing list
>> Xotcl_at_alice.wu-wien.ac.at
>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

Re: [Xotcl] [self class] inside [eval]

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 14 Sep 2004 16:14:31 +0300 (EEST)

On Tue, 14 Sep 2004, Gustaf Neumann wrote:

> I would not recommend this for the general usage, since
> - as uwe pointed out - this is bypassing the xotcl dispatcher
> an can lead to unexpected behavior (it is a defined behavior,
> but different from the variant without eval).

Yes, I let go of that assumption and implementation. It may be good to
mention in the documentation that the eval really is intended for fields
only (although it doesn't state anything about methods anyway, I was just
playing around).

Anyway, thanks for the response.

                               / http://www.fishpool.com/~setok/

Re: [Xotcl] Bug with obs in namespaces

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 09 Sep 2004 14:16:21 +0200

Hi Kirstoffer,

I've produced a fix for this bug. can you please check whether this
xotcl snapshot
works for you?

http://wi.wu-wien.ac.at/~uzdun/resources/xotcl-1.3.2.tar.gz

thanks,

Uwe

Kristoffer Lawson wrote:

>
> This could be related to what others have reported but:
>
> [~/svn/codebase/trunk/tcl] package require XOTcl
> 1.3
> [~/svn/codebase/trunk/tcl] namespace import xotcl::*
> [~/svn/codebase/trunk/tcl] namespace eval foo {
>
>> Class Foo
>> Foo instproc blah {} {puts jou}
>> Foo proc bar {} {puts bar}
>> }
>
> [~/svn/codebase/trunk/tcl] namespace delete foo
> called Tcl_FindHashEntry on deleted table
> Abort
>
>
> / http://www.fishpool.com/~setok/
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl


-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_acm.org, uwe.zdun_at_wu-wien.ac.at

[Xotcl] XOTcl and Thread

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Thu, 10 Feb 2011 14:27:13 +0100

Hello again,

I am trying to add multi-threaded support for my application. I now face
a problem witch combining XOTCl and Thread. The problem is that
::thread::create creates a new instance of interpreter which has own
variables. I can have variables shared between threads using ::tsv
functions. So here is how it looks:

1. Thread #1 creates object myObject and stores in a shared variable:
::tsv::set array1 key1 [MyClass myObject]

2. Thread #2 gets the shared variable and tries to call a proc defined
for MyClass:
set localVar [::tsv::get array1 key1]
$localVar doSomething

At this point second thread will throw en exception saying:
Unknown command 'myObject'

What would be the proper way to "register" the object myObject (which
already exists) in another thread?

-- 
Krzysztof

Next Page