You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
(68) |
Apr
(34) |
May
(17) |
Jun
(4) |
Jul
(36) |
Aug
(23) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(3) |
Feb
(4) |
Mar
(36) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Matthew M. B. <mm...@gw...> - 2008-08-19 20:36:37
|
> > Hi Matt, > > I believe that most (all?) mentors were deferring the $500 gsoc mentor > payment to the Tcl Association. Are you handling that with Clif, or > ?? Do the mentors need to do anything? > > Thanks, > > Jeff > Nice timing---I was planning on sending out several emails tonight about final reports, payments, etc. I need to talk to Clif and work out the details, but I am hoping that since the Tcl conference committee is organized to deal with payments for the conference, they can go ahead and accept the money from Google. But regardless, at the present time, the mentors don't need to do anything. Matt |
From: Alexandros S. <al...@gm...> - 2008-08-19 18:13:38
|
Hi all, This is a progress update for the Tcl-Fuse project (https://sourceforge.net/projects/tcl-fuse). SINCE LAST UPDATE: * FUSE events are now served by Tcl's event loop. * Implemented the "version" subcommand of the "fuse" command, which returns the version of the underlying FUSE subsystem. * Created a Tcl cleanup procedure to automatically erase state and unmount any mounted FUSE file systems when the command is deleted. * Created a comprehensive man page, which includes API documentation for FUSE operation handlers. * Released version 1.0 of this software. * Created a home page for the project at sourceforge (which is the html-generated man page). * Fixed some bugs and various spelling errors. At this state of the project, I consider it completed. I will continue maintaining it though. Therefore, if there are any comments, bugs or remarks please speak out, and I will take a look at it. THE TOTAL DELIVERABLES OF THIS SOC PROJECT (IN BRIEF): 1. A Tcl C extension packed in the standard TEA format, that exposes the full functionality (read & write) of the underlying FUSE subsystem to Tcl. (2413 lines of code) 2. Full user documentation, in the form of a man page. (1169 lines) 3. Thorough testing of the extension, by implementing two use cases: * A "hello" filesystem, identical to the one in FUSE's sources, used for demonstration purposes. (74 lines of code) * The FuseVfs filesystem which exports Tcl's internal filesystem view via FUSE, for other processes to take advantage of. (1085 lines of code - most of them comments) TO FETCH Download the latest version from sourceforge. or svn checkout https://tcl-fuse.svn.sourceforge.net/svnroot/tcl-fuse TO COMPILE On 32bit: autoconf ./configure make sudo make install On 64bit systems: autoconf PKG_CFLAGS="-D_FILE_OFFSET_BITS=64" \ ./configure --with-tcl=/usr/lib64 make sudo make install Detailed instructions in README.tclfuse. REQUIREMENTS: * Kernel with FUSE enabled (CONFIG_FUSE_FS) * Tcl 8.4 or greater * The user mounting a fuse filesystem must be in the "fuse" group (name depends on the distro). TO TRY IT OUT: To mount the "hello" filesystem: cd <root of source code tree> tclsh examples/hello.tcl To mount the FuseVFS filesystem that maps the root of Tcl's VFS: cd <root of source code tree> tclsh examples/test_fusevfs.tcl In both cases the examples/mnt directory is where the filesystems will get mounted. Regards, Alexandros |
From: Ania P. <ani...@gm...> - 2008-08-18 16:59:15
|
UPDATING TK TEST SUITE PROJECT STATUS UPDATE Anna Pawelczyk mentored by Jeff Hobbs -----------------------------------------ABSTRACT----------------------------------------- The Tk test system still uses primarily Tcltest v1, and would benefit from an update to Tcltest v2 and a full reexamination of out-dated tests. The test suite should gain independence from the system's settings that test is made on. This all leads to improvement of testing capabilities. ----------------------------------STATUS UPDATE------------------------------------ Updating Tk test suite required some foregoing preparations and acquaintances. According to that, my work on the project could be divided into 2 main stages I tried to work regularly and make up the delay caused by my exams. I scheduled my work and the hours calculations are done according to the work report that I conducted on http://www.assembla.com/wiki/show/TkTests/Work_report --------------------------------STAGE 1 2008-06-27 - 2008-07-05 During the first stage, I spent 75 hours on the project. In the beginning I had to specify general requirements of the project. I went through already updated Tcl tests, compared them to Tk tests. I conducted tests on different platforms, compared the results, searched for the reasons of failures in tests files, Tcl sources and also C sources. That all also involved familiarizing with Tcl and Tcltests themselves, as the language was new for me. Therefore before 06-27 I spent time on learning the language, skimming the Tcl code, digging wiki pages, reading man pages and learning from "Practical Programming in Tcl and Tk", Brent B. Welch. To better specify my goals, I set up a thread on Tcl-core: http://aspn.activestate.com/ASPN/Mail/Message/Tcl-core/3645438 Also, in the begining I conducted a wiki page, where I was putting my first notices, ideas: http://www.assembla.com/flows/flow/a_KwcurkGr3ztnab7jnrAJ >>>Effects: > This stage resulted in clearly specifying my main goal which is to "bring Tk tests to Tcltest 2.0 syntax, improve clarity, separate tests, eliminate wrong assumtions, dependences among test cases, etc. and try eliminate situations when the test fails because there were made wrong assumptions" and on which I focused in the next stage. > I have identified and fixed a lack of setting -highlightthickness entry's option in constraints.Tcl --------------------------------STAGE 2 2008-07-06 - 2008-08-18 During the second stage, I spent about 310 hours on the project, During this period of time, I focused on bringing Tk tests to Tcltest 2.0 syntax, improving clarity, separating tests, eliminating wrong assumptions, dependences among test cases, etc. The time I had to spend on successive test was decreasing while I was gaining experience. I also tried to optimize my work by writing script - helpers. I spent most of the time on analysing single test cases that were dependent on the others, that failed on some environments, that had extraordinary structure etc. >>>Effects: The result of my work is commited to Tktoolkit's cvs repository. The files that I managed to update are: bgerror.test bind.test bitmap.test border.test button.test canvas.test canvImg.test canvPs.test canvRect.test canvText.test canvWind.test choosedir.test clipboard.test clrpick.test cmds.test config.test cursor.test dialog.test embed.test entry.test event.test focus.test focusTcl.test font.test frame.test geometry.test get.test grab.test grid.test id.test image.test imgBmap.test imgPhoto.test imgPPM.test listbox.test main.test menu.test menubut.test message.test obj.test raise.test safe.test spinbox.test text.test tk.test unixButton.test unixEmbed.test util.test winClipboard.test Which is 52400 lines of code. --------------------------------COMMITMENT----------------------------------- Due to my exams, the project had a late start and will be conducted up to 01-09. -------------------PERSONAL ACHIEVEMENTS---------------------------- The project was an opportunity to join Tcl Community as well as OpenSource Community. I made some steps to learn new language - first steps to got to know Tcl/Tk I learned about the structure of tests, the usage of test suite. I've gone through certain amount of code, learning how to read the sources and search in the sources. And above all I gained huge experience, learned how to conduct a serious project, work remotely, obtain and exchange information with the Community, work using repository. Anna Pawelczyk |
From: Ania P. <ani...@gm...> - 2008-08-18 16:54:35
|
UPDATING TK TEST SUITE PROJECT STATUS UPDATE Anna Pawelczyk mentored by Jeff Hobbs -----------------------------------------ABSTRACT----------------------------------------- The Tk test system still uses primarily Tcltest v1, and would benefit from an update to Tcltest v2 and a full reexamination of out-dated tests. The test suite should gain independence from the system's settings that test is made on. This all leads to improvement of testing capabilities. ----------------------------------STATUS UPDATE------------------------------------ Updating Tk test suite required some foregoing preparations and acquaintances. According to that, my work on the project could be divided into 2 main stages I tried to work regularly and make up the delay caused by my exams. I scheduled my work and the hours calculations are done according to the work report that I conducted on http://www.assembla.com/wiki/show/TkTests/Work_report --------------------------------STAGE 1 2008-06-27 - 2008-07-05 During the first stage, I spent 75 hours on the project. In the beginning I had to specify general requirements of the project. I went through already updated Tcl tests, compared them to Tk tests. I conducted tests on different platforms, compared the results, searched for the reasons of failures in tests files, Tcl sources and also C sources. That all also involved familiarizing with Tcl and Tcltests themselves, as the language was new for me. Therefore before 06-27 I spent time on learning the language, skimming the Tcl code, digging wiki pages, reading man pages and learning from "Practical Programming in Tcl and Tk", Brent B. Welch. To better specify my goals, I set up a thread on Tcl-core: http://aspn.activestate.com/ASPN/Mail/Message/Tcl-core/3645438 Also, in the begining I conducted a wiki page, where I was putting my first notices, ideas: http://www.assembla.com/flows/flow/a_KwcurkGr3ztnab7jnrAJ >>>Effects: > This stage resulted in clearly specifying my main goal which is to "bring Tk tests to Tcltest 2.0 syntax, improve clarity, separate tests, eliminate wrong assumtions, dependences among test cases, etc. and try eliminate situations when the test fails because there were made wrong assumptions" and on which I focused in the next stage. > I have identified and fixed a lack of setting -highlightthickness entry's option in constraints.Tcl --------------------------------STAGE 2 2008-07-06 - 2008-08-18 During the second stage, I spent about 310 hours on the project, During this period of time, I focused on bringing Tk tests to Tcltest 2.0 syntax, improving clarity, separating tests, eliminating wrong assumptions, dependences among test cases, etc. The time I had to spend on successive test was decreasing while I was gaining experience. I also tried to optimize my work by writing script - helpers. I spent most of the time on analysing single test cases that were dependent on the others, that failed on some environments, that had extraordinary structure etc. >>>Effects: The result of my work is commited to Tktoolkit's cvs repository. The files that I managed to update are: bgerror.test bind.test bitmap.test border.test button.test canvas.test canvImg.test canvPs.test canvRect.test canvText.test canvWind.test choosedir.test clipboard.test clrpick.test cmds.test config.test cursor.test dialog.test embed.test entry.test event.test focus.test focusTcl.test font.test frame.test geometry.test get.test grab.test grid.test id.test image.test imgBmap.test imgPhoto.test imgPPM.test listbox.test main.test menu.test menubut.test message.test obj.test raise.test safe.test spinbox.test text.test tk.test unixButton.test unixEmbed.test util.test winClipboard.test Which is 52400 lines of code. --------------------------------COMMITMENT----------------------------------- Due to my exams, the project had a late start and will be conducted up to 01-09. -------------------PERSONAL ACHIEVEMENTS---------------------------- The project was an opportunity to join Tcl Community as well as OpenSource Community. I made some steps to learn new language - first steps to got to know Tcl/Tk I learned about the structure of tests, the usage of test suite. I've gone through certain amount of code, learning how to read the sources and search in the sources. And above all I gained huge experience, learned how to conduct a serious project, work remotely, obtain and exchange information with the Community, work using repository. Anna Pawelczyk |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-13 11:26:36
|
Hi, The TclDtrace binding implementation is complete now[1]. While focus is on writing demos more complicated than the sample program[2], it would be nice to hear some opinions on the API[3] or implementation[4]. Anyone willing to test is welcome with his success/failure reports, bug reports[5] or general thoughts. Hope you'll like it. Kind regards, Remigiusz 'lRem' Modrzejewski PS. TclDtrace is work sponsored by Google as a part of the Summer of Code. [1] - http://dev.lrem.net/tcldtrace/changeset/121/tags/0.4?format=zip [2] - http://dev.lrem.net/tcldtrace/wiki/SampleProgram [3] - http://dev.lrem.net/tcldtrace/wiki/CommandsList [4] - http://dev.lrem.net/tcldtrace/browser/trunk/generic/dtrace.c [5] - http://dev.lrem.net/tcldtrace/report |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-11 16:24:57
|
Daniel A. Steffen wrote: > I would suggest not worrying too much about that problem for now, it > would be a serious pain to reimplement all of tcl's [exec] in TclDTrace... > or were you thinking of using libdtrace's dtrace_proc_create() to run > the command? > that would be useful, but I would do it in addition to [dtrace::grab], Yes, that's exactly what I was going to do. I've, like always, forgot a link to the diff... http://dev.lrem.net/tcldtrace/wiki/CommandsList?action=diff&version=53 > not instead of (it is very common to want to grab a longrunning process, > as with 'dtrace -p'), e.g. [dtrace::launch] might be an ok command name > for that functionality ? This seems nicer. Changing that to launch. Kind regards, Remigiusz Modrzejewski |
From: Daniel A. S. <da...@us...> - 2008-08-11 14:21:52
|
Hi Remigiusz, sorry for the delay, I have been very busy in the last few days, deadline coming up... have not had time yet to look at the aggregations issue, will try to do it soon, FWIR it should be possible to get at the aggregation names, it's inconvenient not to have that info in the [dtrace::aggregations] output. On 11/08/2008, at 15:27, Remigiusz Jan Andrzej Modrzejewski wrote: > I've realised, that a call to exec followed by a call > to ::dtrace::grab is not really a good idea... A quick process may > actually be gone before we grab it. Tested with /bin/true. I'm not > all that sure of the command name - better ideas welcome. I would suggest not worrying too much about that problem for now, it would be a serious pain to reimplement all of tcl's [exec] in TclDTrace... or were you thinking of using libdtrace's dtrace_proc_create() to run the command? that would be useful, but I would do it in addition to [dtrace::grab], not instead of (it is very common to want to grab a longrunning process, as with 'dtrace -p'), e.g. [dtrace::launch] might be an ok command name for that functionality ? Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-11 13:26:58
|
Hi, I've realised, that a call to exec followed by a call to ::dtrace::grab is not really a good idea... A quick process may actually be gone before we grab it. Tested with /bin/true. I'm not all that sure of the command name - better ideas welcome. Kind regards, Remigiusz Modrzejewski |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-08 22:43:50
|
Hi, I've finally got 0.3 up there. I was bogged down by some random happenings, weather and missed effort. But finally aggregations support is there, with process grabbing being the last missing feature. I still have some cleanup in the queue, and finally the demonstration scripts. But I have to get off this weekend - my beloved one has birthday, and I don't want to have laptop with me on that travel. So - till monday. Kind regards, Remigiusz Modrzejewski |
From: Daniel A. S. <da...@us...> - 2008-08-06 22:31:46
|
Hi Remigiusz, On 05/08/2008, at 21:53, Remigiusz Jan Andrzej Modrzejewski wrote: >> I could just commit the new buildsystem at the top level of the the >> tcldtrace dir and leave the temporary Makefile in generic alone, so >> your >> ongoing work shouldn't be disturbed (would be annoying to do as a >> patch >> as new dirs and many new files need to be added) > > Looking forward for this. done, TEA buildsystem committed in r93-96. I also adjusted the existing generic/Makefile to build with the same defines as the TEA buildsystem and run the testsuite in the same way (r97-100). in particular this now builds with -DTCL_THREADS, which uncovered a minor error in Tcl_MutexLock/Tcl_MutexUnlock usage (they take a mutex ptr), fixed in r101; also the TEA buildsystem has more warnings enabled, the three minor fixes in r102 silences them (one was my fault in the #27 patch). I've tested the new buildsystem on Mac OS X and on Solaris nv 94 (with both gcc and sun cc as well as gmake and make). >> I could also look at transforming the current wiki CommandsList page >> into manpage format, e.g. *roff directly or probably better the >> tcllib >> doctools format, which would give us a start for included >> documentation >> and would give you time to write the more important docs, like a >> detailed README and e.g. some examples (along with the demos). > > I thought of just copy-pasting the wiki page and transforming > formatting > with a bunch of regexps. that's pretty much what I was thinking of doing as well, in any case it's probably better to wait until the CommandsList is final (in particular until #26 is done)... the committed dtrace.n and README files are just stubs for now, they're mainly there to make the 'install' and 'dist' targets work... Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Jeff H. <je...@ac...> - 2008-08-06 17:08:35
|
Remigiusz Jan Andrzej Modrzejewski wrote: > Jeff Hobbs wrote: >> for (i = 0; i < 3; i++) { Tcl_IncrRefCount(objv[i]); } >> >> 706 if (Tcl_EvalObjv(arg->hd->interp, 3, objv, 0) != TCL_OK) { >> 707 /* What now?! */ > > [...] >> 708 } >> >> for (i = 0; i < 3; i++) { Tcl_DecrRefCount(objv[i]); } > > OMG! That did the trick... But I was ready to bet money on that > Tcl_EvalObjv does it for me. Then I'm surprised I got this far without > stumbling upon this. It is documented to be necessary, and it depends on the path through T_EO whether you can hit the crash condition otherwise. It's discussed in http://sourceforge.net/tracker/index.php?func=detail&aid=730244&group_id=10894&atid=110894, but personally I think it's still waiting for a fix in the core. Jeff |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-06 13:24:54
|
Jeff Hobbs wrote: > for (i = 0; i < 3; i++) { Tcl_IncrRefCount(objv[i]); } > > 706 if (Tcl_EvalObjv(arg->hd->interp, 3, objv, 0) != TCL_OK) { > 707 /* What now?! */ > [...] > 708 } > > for (i = 0; i < 3; i++) { Tcl_DecrRefCount(objv[i]); } OMG! That did the trick... But I was ready to bet money on that Tcl_EvalObjv does it for me. Then I'm surprised I got this far without stumbling upon this. Thanks a lot :) Kind regards, Remigiusz Modrzejewski |
From: Daniel A. S. <da...@us...> - 2008-08-06 00:36:45
|
Hi Remigiusz, On 06/08/2008, at 1:20, Remigiusz Jan Andrzej Modrzejewski wrote: > > Not the first, probably not the last - problem with Tcl_EvalObjv. with the changes made to the testsuite in #25 (to make it run on Mac OS X), I cannot reproduce this crash... I'll have a more detailed look tomorrow (on solaris) > The test should fire the callback two times for probes > syscall::exec:entry and syscall::exec:return. that now works fine for me (against tcl 8.4, need the new buildsystem first to easily test against 8.5) One possible point of confusion I note is with handling of 'args' (both in the testsuite and in the spec & code), note that the 'args' name is special in tcl argument lists, if it is in the last position, it signifies 0 or more optional arguments (passed to the proc as a list in the 'args' var), i.e. something like % proc callback {probe args} {set args} will return % puts [list [callback p]] {} % puts [list [callback p {}]] {{}} % puts [list [callback p x y]] {x y} to avoid confusion, IMO an API like [::dtrace::list $p callback] should thus be followed by an optional number of arguments, and not a single list of arguments, and similarly for the callbacks that take 'args' (which probably means the order of the arguments to the 'probe_output' callback should be changed so that the optional args come last) > BTW - how should I signalize an error within the callback? Like the > failed Tcl_EvalObjv (if it would ever fail without bringing the > whole thing down)? via bgerror, that's the standard way in tcl to report errors from callbacks like event handlers etc, c.f. Tcl_BackgroundError(3) Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Jeff H. <je...@ac...> - 2008-08-06 00:33:47
|
Remigiusz Jan Andrzej Modrzejewski wrote: > Not the first, probably not the last - problem with Tcl_EvalObjv. Now > I've got this here: > http://dev.lrem.net/tcldtrace/browser/trunk/generic/dtrace.c#L680 > When executing this test: > http://dev.lrem.net/tcldtrace/browser/trunk/tests/dtrace.test#L484 > I get a segfault. This is during the second call of callback. Everything > looks quite the same as in the first call. Some gdb dump: 691 static int listProbe ( 692 dtrace_hdl_t *handle, 693 const dtrace_probedesc_t *pdesc, 694 void *varg 695 ) 696 { 697 list_arg *arg = (list_arg*) varg; 698 Tcl_Obj *objv[3]; int i; 699 700 objv[0] = arg->proc; 702 objv[1] = formatProbeDesc(arg->hd, pdesc); 704 objv[2] = arg->args; for (i = 0; i < 3; i++) { Tcl_IncrRefCount(objv[i]); } 706 if (Tcl_EvalObjv(arg->hd->interp, 3, objv, 0) != TCL_OK) { 707 /* What now?! */ Tcl_AddErrorInfo(arg->hd->interp, "\n (running listProbe callback)"); Tcl_BackgroundError(arg->hd->interp); return -1; // ERROR CONDITION RESULT?? 708 } for (i = 0; i < 3; i++) { Tcl_DecrRefCount(objv[i]); } 710 return 0; 711 } > The test should fire the callback two times for probes > syscall::exec:entry and syscall::exec:return. > > BTW - how should I signalize an error within the callback? Like the > failed Tcl_EvalObjv (if it would ever fail without bringing the whole > thing down)? I chose background error as that does the bgerror style reporting, as is probably necessary in this error situation. Otherwise you need to set the interp result and trigger a TCL_ERROR return code. Jeff |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-05 23:20:29
|
Hi, Not the first, probably not the last - problem with Tcl_EvalObjv. Now I've got this here: http://dev.lrem.net/tcldtrace/browser/trunk/generic/dtrace.c#L680 When executing this test: http://dev.lrem.net/tcldtrace/browser/trunk/tests/dtrace.test#L484 I get a segfault. This is during the second call of callback. Everything looks quite the same as in the first call. Some gdb dump: #v+ (gdb) p *objv[0] $11 = {refCount = 1, bytes = 0x81aa938 "callback", length = 8, typePtr = 0xfef9e5b8, internalRep = {longValue = 139022144, doubleValue = 6.8686065361594778e-316, otherValuePtr = 0x8494f40, wideValue = 139022144, twoPtrValue = {ptr1 = 0x8494f40, ptr2 = 0x0}}} (gdb) p *objv[1] $12 = {refCount = 3, bytes = 0x0, length = 0, typePtr = 0xfef9e498, internalRep = {longValue = 135929976, doubleValue = 6.7158331381625143e-316, otherValuePtr = 0x81a2078, wideValue = 135929976, twoPtrValue = {ptr1 = 0x81a2078, ptr2 = 0x0}}} (gdb) p *objv[2] $13 = {refCount = 1, bytes = 0xfef9e674 "", length = 0, typePtr = 0x0, internalRep = {longValue = 138565592, doubleValue = 6.8460498702854665e-316, otherValuePtr = 0x84257d8, wideValue = 138565592, twoPtrValue = {ptr1 = 0x84257d8, ptr2 = 0x0}}} (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xfef4ff59 in Tcl_NewStringObj () from /opt/tcldebug//lib/libtcl8.5.so (gdb) bt #0 0xfef4ff59 in Tcl_NewStringObj () from /opt/tcldebug//lib/libtcl8.5.so #1 0xfef52f82 in AppendPrintfToObjVA () from /opt/tcldebug//lib/libtcl8.5.so #2 0xfef531ca in Tcl_ObjPrintf () from /opt/tcldebug//lib/libtcl8.5.so #3 0xfef3adb0 in Tcl_LogCommandInfo () from /opt/tcldebug//lib/libtcl8.5.so #4 0xfeec1983 in Tcl_EvalObjv () from /opt/tcldebug//lib/libtcl8.5.so #5 0xfeb92e36 in listProbe (handle=0x84554a8, pdesc=0x8045d3c, varg=0x8045f5c) at dtrace.c:706 [and a lot more] #v+ Now, why would the refCount equal to 3? It's created just two lines before. It's the only visible difference between this and the previous instance of the function. I have no idea what to try now... Any help? The test should fire the callback two times for probes syscall::exec:entry and syscall::exec:return. BTW - how should I signalize an error within the callback? Like the failed Tcl_EvalObjv (if it would ever fail without bringing the whole thing down)? Kind regards, Remigiusz Modrzejewski |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-05 19:53:36
|
Daniel A. Steffen wrote: > looking at the roadmap and open tickets, there appears to still be quite > a bit of implementation work left to do, which will probably take you at > least the rest of this week, what do you think? We'll see. I've managed to do the buffered output and listing (just committed that, test suite in the works) today. So I'm left with aggregations, which should not take more than a full day. Default handlers will be trivial. So the only question is - how long will it take to do proper process handling. > I think it is important to reserve a full week to write some cool demos > (i.e. milestone 5), which leaves us with not much time for milestone 4... > As you've been writing the testsuite along with the implementation > (testsuite looking good BTW), the main tasks remaining in milestone 4 > are the TEA buildsystem and the docs. > > what would you think of me helping out with a bit with these? You're the expert - I can be only happy to get it done by you. Especially that I already got quite rusty with autohell... I had problems with supporting my old autohell code last week :/ > I could just commit the new buildsystem at the top level of the the > tcldtrace dir and leave the temporary Makefile in generic alone, so your > ongoing work shouldn't be disturbed (would be annoying to do as a patch > as new dirs and many new files need to be added) Looking forward for this. Then I'll do aggregations tomorrow, so this may lead to a real beta release shortly :) > I could also look at transforming the current wiki CommandsList page > into manpage format, e.g. *roff directly or probably better the tcllib > doctools format, which would give us a start for included documentation > and would give you time to write the more important docs, like a > detailed README and e.g. some examples (along with the demos). I thought of just copy-pasting the wiki page and transforming formatting with a bunch of regexps. If you've got the spare time to do it better - you're welcome. Kind regards, Remigiusz Modrzejewski |
From: Ania P. <ani...@gm...> - 2008-08-03 15:35:39
|
Hi, This is a status update for the Updating Tk test suite project by Ania Pawelczyk mentored by Jeffrey Hobbs -----------------------------------------ABSTRACT----------------------------------------- The Tk test system still uses primarily tcltest v1, and would benefit from an update to tcltest v2 and a full reexamination of out-dated tests. The test suite should gain independence from the system's settings that test is made on. This all leads to improvement of testing capabilities. -------------------------------PROJECT MAIN GOALS------------------------------- 1. Bring all tests to tcltest 2.0 syntax, improve clarity, separate tests, eliminate wrong assumtions, dependences among test cases, etc. 2. Eliminate situations when the test fails because there were made wrong assumptions etc. ---------------------------------CURRENT STATUS----------------------------------- > investigated some failing tests (link3) > Identified and fixed fonts constraint wrong assumtion (link1, constraints.tlc) > realized project main goals to the following tktests (available through link1): bell.test bgerror.test bind.test bitmap.test border.test button.test cmds.test cursor.test dialog.test get.test entry.test message.test spinbox.test text.test ------------------------------------------TO DO------------------------------------------------ > realize project main goals to all the tktests, firstly mainly taking care of updating all the tktests (PROJECT MAIN GOAL nr1) -----------------------------------PROJECT PAGES------------------------------------- (link1 -SourceForge cvs; login aniap) http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/tests/ (link2- project wiki page) http://www.assembla.com/wiki/show/a_KwcurkGr3ztnab7jnrAJ (link3- questions and suggestions threads) http://www.assembla.com/flows/flow/a_KwcurkGr3ztnab7jnrAJ I'm looking forward to any comment or suggestion, especially for the already updated tests (mentioned in the CURRENT STATUS, available through link1) Regards. Ania Pawelczyk |
From: Remigiusz J. A. M. <lr...@go...> - 2008-08-02 18:59:11
|
Hi, I've overcome the bugs and finally have a first version of TclDtrace that actually lets you see something working: http://dev.lrem.net/tcldtrace/browser/tags/0.1 Though the build system is not there yet. I've got this program running: http://dev.lrem.net/tcldtrace/wiki/SampleProgram And hope for things to go really fast now. Stay tuned :) Kind regards, Remigiusz Modrzejewski |
From: Daniel A. S. <da...@us...> - 2008-07-24 14:21:57
|
Hi Remigiusz, On 24/07/2008, at 16:03, Remigiusz Jan Andrzej Modrzejewski wrote: > I've got a bunch of repeating code blocks currently in Open(). Now, > I would fold this into a macro, to avoid the repeating. But on the > other hand, many people grieve about any macro usage that has more > than one line. What should I do now? I agree it would be nice to do some refactoring to eliminate similar code, in particular the error handling throughout the whole of dtrace.c is very similar and could probably be factored out into a single macro or maybe even into an inline function (with gcc, inline functions are just as fast as macros but cleaner, OTOH I personally have nothing against multiline macros, as long as they are at the top of dtrace.c and not into dtrace.h) if the error checking and handling in Open() were abstracted away, it would certainly make the function easier to read, enough to make other factoring out unnecessary IMO. it should be possible to have a single macro/function that does the error condition checking, calls Tcl_AppendResult(), Tcl_SetErrorCode() (optionally also doing the errnum sprintf) as well as optionally closing and/or deleting the handle. there are also other opportunities for refactoring, e.g. in Dtrace_Init() you could use a static array and call Tcl_CreateObjCommand in a loop instead of repeating the call multiple times, but I would not worry about that type of change too soon... Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Remigiusz J. A. M. <lr...@go...> - 2008-07-24 13:37:21
|
Daniel A. Steffen wrote: > just submitted a small dtrace.test patch that makes the r64 testsuite > pass on Mac OS X with tcl 8.4 (it does not fix the new failures > introduced with r66 of course)... Committed already. And I already found source of that breakage (it doesn't like to have the errhandler registered), I'm trying to figure out how to fix that. > looks like you have been making good progress recently, everything added > this week looks great, so no need for any comment from my end... Actually, I've got some bad days. Especially yesterday... The whole place around turned into construction site (one new building on the other side of the street, next building - school undergoing serious renovation, flat below me neighbors having walls rearranged and so on), not a single line of code throughout whole day :/ > That's also why I have not proceeded yet with the crucible review, I see > nothing urgent that would need changing right now, so IMO we can wait to > do the review until the implementation is more complete, but if you'd > prefer I can do it sooner of course? I'm certainly not urging on this. You're already very helpful... And I'm just going to do some groundbreaking part of code - first usable version to be released before weekend :) Kind regards, Remigiusz Modrzejewski |
From: Daniel A. S. <da...@us...> - 2008-07-24 13:28:45
|
Hi Remigiusz, just submitted a small dtrace.test patch that makes the r64 testsuite pass on Mac OS X with tcl 8.4 (it does not fix the new failures introduced with r66 of course)... looks like you have been making good progress recently, everything added this week looks great, so no need for any comment from my end... That's also why I have not proceeded yet with the crucible review, I see nothing urgent that would need changing right now, so IMO we can wait to do the review until the implementation is more complete, but if you'd prefer I can do it sooner of course? Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Daniel A. S. <da...@us...> - 2008-07-21 15:41:28
|
Hi Remigiusz, On 21/07/2008, at 17:28, Remigiusz Jan Andrzej Modrzejewski wrote: > I've just committed test suite for ::dtrace::exec. Now I have a a > question, how do I construct a constraint to check whether I'm root? I'm not sure you actually want a constraint that tests for root, what you really care about is whether you have tracing privileges, no? e.g. on Solaris, an ordinary user can have various privs that give access to more or less of dtrace: http://wikis.sun.com/display/DTrace/Security (on Mac OS X, you do indeed need to be root for any of these) it might be best to have four constraints for the different levels of privs possible. To construct them, the easiest and most portable way would probably be to try and do a [dtrace] operation that requires the given privileges level, or if you want to stay independent of the [dtrace] implementation, you could [exec] the dtrace(1) tool with an action that requires the given priv level. > And... Will you reveal the evaluation, please? I sent you the final eval via email on the 15th, 14:09 CEST (ccd to mentors), if you did not receive it let me know, I can resend it... Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Alexandros S. <al...@gm...> - 2008-07-17 16:42:10
|
Hi all, This is a progress update for the Tcl-Fuse project (https://sourceforge.net/projects/tcl-fuse). SINCE LAST UPDATE: * Implemented all the proxy functions that establish an interface between: FUSE API <=> Tcl procedures * Completed the FuseVFS extension that fully exports Tcl's VFS to userspace, via FUSE. * Preliminary API documentation in examples/fusetcl.tcl FUSEVFS: Code at: examples/fusevfs.tcl The FuseVFS extension is implemented in Tcl using the tcl-fuse C extension. It exports the Tcl's VFS on userspace, via FUSE. Based on what it is provided by Tcl, the following FUSE operations have been implemented and tested: getattr readdir readlink open read write rename mknod mkdir unlink rmdir chmod chown symlink link truncate access utimens truncate access flush fsync Whereas the following were not implemented: statfs setxattr getxattr listxattr removexattr opendir releasedir fsyncdir create ftruncate fgetattr destroy lock bmap release either because they weren't necessary (ftruncate, fgetattr, fsyncdir), applicable (bmap), or the necessary information are not provided by Tcl at all (statfs, setxattr, getxattr, listxattr, removexattr). For example, Tcl's VFS does not support "exteded attributes", hence we cannot provided them to FUSE. An other limitation of Tcl's VFS is that it does not support create of fifos, sockets, & device files, and hence it is not supported in FuseVFS either. The release, opendir, and releasedir operations are not necessary due to the state-less nature of this implementation. A state-full version is planned for implementation, which will have greater performance and more thoroughly test tcl-fuse. * Implement a few subcommands of the "fuse" command, namely: delete, version, info & unmount. * Create Tcl cleanup procedures to automatically erase state. * Integration of FUSE events to Tcl's event loop and threading model. * Documentation (man page). TO FETCH svn checkout https://tcl-fuse.svn.sourceforge.net/svnroot/tcl-fuse TO COMPILE On 32bit: autoconf ./configure make sudo make install On 64bit systems: autoconf PKG_CFLAGS="-D_FILE_OFFSET_BITS=64" \ ./configure --with-tcl=/usr/lib64 make sudo make install Detailed instructions in README.tclfuse. REQUIREMENTS: * Kernel with FUSE enabled (CONFIG_FUSE_FS) * Tcl 8.5 * The user mounting a fuse filesystem must be in the "fuse" group (name depends on the distro). TO TRY IT OUT: To mount the "hello" filesystem: cd <root of source code tree> tclsh examples/hello.tcl To mount the FuseVFS filesystem that maps the root of Tcl's VFS: cd <root of source code tree> tclsh examples/test_fusevfs.tcl In both cases the examples/mnt directory is where the filesystems will get mounted. Next status update will come after one or two weeks. Regards, Alexandros |
From: Matthew M. B. <mm...@gw...> - 2008-07-15 16:04:23
|
All, I am pleased to report that the Tcl group turned in all mentor and student surveys on time! Which is apparently not the case for several other groups. Matt |
From: Alexandros S. <al...@gm...> - 2008-07-13 18:30:43
|
Hi all, This is a status update for the Tcl-Fuse project (https://sourceforge.net/projects/tcl-fuse). For those that don't know what tcl-fuse is: It's a Tcl interface to the linux kernel's FUSE subsystem. It provides a Tcl extension that exports the full functionality of the underlying FUSE kernel feature to the Tcl programming language. FUSE, which stands for File-System in User-Space, is a kernel subsystem and accompanying library that allows regular programs to implement a filesystem completely in userspace. The filesystem operations are received by the kernel via the standard Linux VFS interface, and are dispatched to a resident user process for handling (daemon). This extension will enable for: * Easy creation of FUSE filesystem written solely in Tcl * Export of the Tcl VFS via FUSE for all system processes to take advantage. THE DESIGN: The entry point is a new Tcl command named "fuse". This command establishes a binding between FUSE operations and Tcl procedures. It creates a new command for every FUSE filesystem, that can be used to mount it on a specific filesystem directory. There is a proxy C function for every FUSE operation. The proxy function is invoked by FUSE and its job is to translate the C API to a Tcl API, and vice versa for the return value of the Tcl procedure. Currently the level of integration with FUSE is low. This will be improved in due course. For instance, mount parameters are parsed by FUSE, whereas the FUSE events are not handled by Tcl's event loop (which remains stalled). CURRENT STATUS: * Created a TEA build tree and adapted it for the needs of this Project. * Completed a first version of the extension with support for the "getattr", "readdir", "read", "open" and "rename" FUSE operations. * Ported the example hello FUSE filesystem (examples/hello.c in FUSE's source tree) to Tcl (examples/hello.tcl in tcl-fuse's source). * Created a preliminary TclVFS to FUSE Tcl interface (examples/fusevfs.tcl in tcl-fuse's source), that is limited to the aforementioned FUSE operations. WHAT'S COMING NEXT: * Implement the proxy functions for the remaining FUSE operations. * Implement a few subcommands for the "fuse" command, namely: version, unmount, info, context * Create Tcl cleanup procedures to automatically erase state. * Integration of FUSE events to Tcl's event loop and threading model. * Complete the FuseVFS extension. * Documentation (man page). TO FETCH svn checkout https://tcl-fuse.svn.sourceforge.net/svnroot/tcl-fuse TO COMPILE On 32bit: autoconf ./configure --prefix=/usr/local make sudo make install On 64bit systems: autoconf PKG_CFLAGS="-D_FILE_OFFSET_BITS=64" \ ./configure --with-tcl=/usr/lib64 make sudo make install Detailed instructions in README.tclfuse. REQUIREMENTS: * Kernel with FUSE enabled (CONFIG_FUSE_FS) * Tcl 8.5 TO TRY IT OUT: To mount the "hello" filesystem: cd <root of source code tree> tclsh examples/hello.tcl To mount the FuseVFS filesystem that maps the root of Tcl's VFS: cd <root of source code tree> tclsh examples/test_fusevfs.tcl In both cases the examples/mnt directory is where the filesystems will get mounted. I'm looking forward to feedback. Alexandros |