Prev: How to access a DLL in Tcl/Win32 ?
Next: Changing icon on script
From: Donal K. Fellows on 31 Jan 2010 04:20
On 30/01/2010 21:40, tom.rmadilo wrote:
> * One method is to migrate a scalar variable to an array where the key
> is added to the API signature,
> * Another method is to use some type of object system (TclOO uses a
> unique namespace to protect data),

TclOO deliberately doesn't protect its objects very heavily; the
mechanism it does provide (hiding of methods, being coy about the NS
name) is really just advisory. The aim is that you get encouraged to
write good code, but when you need something complex - debuggers were my
original thought, and there are other things too - you can do that too.
Of course, that means they're not secure, but Tcl's security boundaries
are between interpreters (and hence threads).

> * Instead of an array you can directly use a namespace, which allows
> more than one variable to be easily referenced with a particular key
> (I'm guessing this is why TclOO uses namespaces).

The other advantage of a namespace is that you've got full access to all
the machinery for working with variables (arrays, upvar, traces, etc.)
which makes it very easy to do sophisticated things. If you simulate
things, it becomes much more complex and you lose features round the
edges (e.g., using an array as the storage space means you lose the
ability to actually put an array in there).

In addition, I believe that supporting OO systems was part of the
original design brief for namespaces. (Well, they were adopted with
modifications from itcl, though the modifications caused problems. Not
that I know the details.)

Donal.
From: tom.rmadilo on 31 Jan 2010 14:14
On Jan 31, 1:20 am, "Donal K. Fellows"
<donal.k.fell...(a)manchester.ac.uk> wrote:

> In addition, I believe that supporting OO systems was part of the
> original design brief for namespaces. (Well, they were adopted with
> modifications from itcl, though the modifications caused problems. Not
> that I know the details.)

I've only briefly played around with any of the object systems in Tcl,
but one reason I have avoided in the past...prior to TclOO is that the
most interesting ones lacked the ability to fully introspect their
state. This is a huge disadvantage for me because I usually write code
which writes code, and debugging requires introspection.

But then I started using namespaces as object containers. Many of the
features seem amazingly useful and I've since wondered why so little
is said about namespaces. Usually they are presented as a thin
strategy to avoid name collision when developing library/package
code.

I think TclOO is a bold move into this space. What is currently
missing is example code which explores the possibilities. Maybe stuff
is showing up on the wiki. Something more structured might help.
From: mikeday on 17 Feb 2010 18:07
On Jan 29, 9:40 pm, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:
> On Jan 29, 6:06 pm, mike...(a)webmail.us wrote:
>
>
>
> > Hi All,
>
> > I'm really liking Tcl and have decided to use it as the primary
> > language for my current project.  However, I haven't found an
> > affordable (free or low cost!) cross-platform deployment solution that
> > includes all of the following packages:
>
> > Tcl 8.5
> > Tk
> > Itcl
> > Sqlite
> > Threads
>
> > It also needs to support at least the following platforms:
>
> > Windows (2000, XP, and on)
> > Unix/Linux
> > Mac OS X
> [snip]
> So the issue boils down to packaging?

Packaging for deployment, yes. I was basically asking if pre-compiled
binaries with tclkit-like functionality exist with the above packages
included, for the above operating systems.

> Seems like the immediate issue
> should be program design. You could test the different component
> packages on each platform to assure yourself that they work and work
> together. You'll need that experience before moving on to a cross-
> platform deployment solution, if one exists.

Well I agree that in principle I should focus on actually developing
the thing before I worry about how to distribute it. :) In my case
however I was still trying to decide whether or not to commit to TCL
before going forward with this project.

The mere fact that so many "builds" like dqkit, tclkit, freewrap, and
kbskit exist is encouraging. When the time for deployment comes,
these examples give me confidence that if a solution does not already
exist, I can mod and compile one myself (I've been a C/C++ developer
for many years before finding TCL).

I'm definitely sticking with TCL for now.

Thanks, and sorry for the late reply (life happens),
- Mike
From: mikeday on 17 Feb 2010 18:43
On Jan 30, 12:42 pm, tomk <krehbiel....(a)gmail.com> wrote:
> I would recommend that you use the Active State distribution, here is
> the man page for their packageshttp://docs.activestate.com/activetcl/8.5/at.pkg_index.html.

Thanks. I started with Active State, then switched to a combination
of their docs and tclkit for my runtime, long before posting my
original message. The problem with Active State's distribution is it
doesn't come with a free one-file deployment solution like tclkit,
unless I missed something...

> I would also point out that is extreamly unlikely that you need to use
> threads, as you do with other languages, because tcl unlike other
> languages, has a built in event model that does all the work for you.
> Please discuss your need for using threads with the tcl experts be for
> going down that path.
> tomk

I love TCL's event model, but so far it doesn't seem adequate for my
situation.

Like I said in the original post, my system involves mutliple AI's
considering a situation simultaneously. Eventually, some of the AI's
are going to be written by third parties, so I will not have direct
control over their quality, and will have to make it as easy as
possible for those third party developers.

That said, my current prototype works without threads, but only by
riddling my AI code with calls to "update". It also has the drawback
that only one AI can be "thinking" at a time.

Here's some pseudocode:

proc ai_getaction {current_situation} {
foreach action [all_possible_actions $current_situation] {
score $action
update
}
return [highest_scored_action]
}

(an overly simple approach, just meant to be illustrative for this
discussion)

That let's the UI remain reasonably responsive only if "score" doesn't
take much computation time. If it does, then I have to inject calls
to "update" within it. I could just liberally sprinkle "update"
within every loop in every bit of AI code, but that seems barbaric.
AND this approach is totally inadequate if I want two calls of
"ai_getaction" doing their thing simultaneously. For that I'd have to
break up the whole calculation into chunks, maintaining state
separately, etc...

With a thread-based approach, I could focus simply on writing good AI
code, and so could the eventual third-party developers. Also, I could
make the UI as responsive as I wish by altering the priority of the AI
thread.

Thank you for your reply and sorry for my late reply,
- Mike
From: Uwe Klein on 18 Feb 2010 04:18
mikeday(a)webmail.us wrote:
> With a thread-based approach, I could focus simply on writing good AI
> code, and so could the eventual third-party developers. Also, I could
> make the UI as responsive as I wish by altering the priority of the AI
> thread.

Are your AI-engines "contained" ?

What about spawning them as separate process connected
via narrow interfaces ?
>

uwe
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How to access a DLL in Tcl/Win32 ?
Next: Changing icon on script