Updated 2017-07-12 22:21:02 by dkf

Detailed information is available at http://www.eurotcl.tcl3d.org.

See the program page for presentations and photos.
WhenJuly 8-9, 2017
WhereBerlin, Germany
Email Contactmailto:[email protected]
Site ChairMartin Lemburg
Program ChairPaul Obermeier

Thanks to Christian Gollwitzer and Martin Lemburg for doing a very good local organization.

Thanks also to Martyn Smith for taking photos of the event.

31 Tcl'ers from Austria, Estonia, France, Germany, Netherlands, Russia, Spain, Sweden, UK and USA attended the meeting.

2 TCT members attended the meeting: Brian Griffin, Donal Fellows.

The following company sponsored the meeting:

The following Tcl'ers gave a presentation. Now available on the EuroTcl site.
Florian MurrMcFSM - A Vast Extension to Finite State Machines
Franz VaterOrganizing information, projects and communities by an information server based on tclhttpd
Christian GollwitzerControlling Large-Scale Experiments with AsynCA, a modern Tcl extension for EPICS channel access
Uli EnderUsing GPIOs of Raspberry Pi in pure Tcl - my way
Manfred RosenbergerRefactoring approaches for rattleCAD, a domain specific CAD-application written in pure Tcl
Carsten BellonaRTist - An Industrial-Radiology Simulator Using Tcl/Tk and VTK
Leonid VovchukTcl as automation tool in mechanical calculations
Steve ShawHammerDB, load testing and benchmarking databases with Tcl/Tk
Alexandru DadalauMechanical Simulations with Tcl/Tk
Nathan CoulterAn Event Loop For Coroutines
Arjen MarkusWork-in-Progress: Renewal of a tutorial
Arjen MarkusWork-in-Progress: Mathematcl
Donal FellowsTclQuadcode Status
Donal FellowsTcl/Tk Status
Adrien PeulvastRBC (BLT) and canvas use for metro system testing and simulation
Han TheIPEnv. A Tcl/Tk-based integrated programming environment

DKF: Here's some quick notes on things that people want to see done. No particular sorting.

  • Clarity from ActiveState on the TDK's long-term status
  • lsort's -dictionary option ordering to be available in string compare and lsearch.
  • String distance metric (e.g. Levenshtein) via new command: string distance.
  • Standard way of doing async I/O with coroutines
  • Basic beyond-the-BMP support (discussion with chw et al)
    • We think it's enough to convert internally to surrogate pairs in 8.7 when we're using at least the "string" type. Important thing is to be able to take a UTF-8 input from outside Tcl (e.g., of an emoji) and to be able to pass it through and get the same character out at the end when we output the string.
    • chw: in our conversation I've mentioned what I tried in an AndroWish branch, see the timeline following https://www.androwish.org/index.html/info/110db5bc0c75e914
  • TIP 469: A Callback for Channel-Exception Conditions”
  • Specialized type and accompanying commands for numerical data (inspired by Vectcl) - added by AM, a small group (Arjen, Jima, Christian, ...) will write a TIP on this.

I'm probably missing some. Please add in. (This is temporary area until we fold these into the main wishlists, etc.)

HaO: Donal, did you discuss about the TDK's status? IMHO specially the TCL compiler is crucial technology. Andreas wrote on CLT, that there are important pieces at ActiveState about that...
DKF: I've chatted with aku, and he said "teacup will be open source. TDK is still sold to enterprises, just not to individual devs anymore. you should talk to [email protected]".
We then talked a bit further, and I'm of the opinion that the main risk is the debugging support, and that tclquadcode (possibly with zipkits for packaging) will end up being a much better obfuscator than the TDK's "compiler" ever was. Reverse-engineering a ton of machine code with NO symbols (remember, we can build in stub-enabled mode with just one public defined symbol, the init function) and few strings will be astonishingly difficult, especially as the code doesn't really look much like that which comes out of a normal C compiler; our implementations use some compiler intrinsics that don't get normally generated from C code. (Also, Komodo is clearly ActiveState's product, but then it always felt like it was.)
aku's main concern was that the obfuscator should not be a barrier to adoption of 8.6 or future versions of Tcl. I can definitely be on board with that!

jima: Donal, in discussions with Florian Murr he seemed interested in having an "array pop" feature (he used another name for it, sorry I can't remember). A command that given an array would just pop an element from it, let it be random or just the first.

Also, apparently the fact that anti-aliasing is not present in Tk canvas (although other alternatives exists as in TkPath) seems to be hurting some of our users. So here is another request: anti-aliasing in the core.
DKF: I don't remember the "array pop" stuff at all; I need to look through all the presentations once again to find out what ideas/wishes were in there (as I didn't start recording them properly until the second day because I was too busy with writing my own two presentations on the first). The anti-aliasing issue is a bit silly, because the canvas is anti-aliased on OSX and has been for a very long time. Replacing the implementation so that it can anti-alias on other platforms is entirely possible. (Well, text should usually be AAd on every platform now unless someone insists on using the old X11 font renderer, and images will depend on the image renderer, just as windows will be up to that window.)

bll: Also related to the canvas, I remember a comment from an EDA user that stated that they would stay with Tcl/Tk 8.4 because the canvas was too slow in 8.6.
DKF: The canvas slowness could be one of a few things, but the likely culprits are the advanced tag search engine, the new text renderer, or the alpha channel in images. The latter two are particularly likely to cause problems when using remote displays, as there's a lot of stuff in those areas where we're not able to hand off to the Xserver nicely in our current implementation.

jima: On Sunday, after the conference, I was able to have a little walk on sunny Berlin...

Please find some (dubious quality) photos here.