[fossil-users] 3rd Call For Papers - 23rd Annual Tcl/Tk Conference (Tcl'2016)
Hello Fossil Users, fyi ... 23rd Annual Tcl/Tk Conference (Tcl'2016) http://www.tcl.tk/community/tcl2016/ November 14 - 18, 2016 Crowne Plaza Houston River Oaks 2712 Southwest Freeway, 77098 Houston, Texas, USA [[ 7...6...5...4...3...2...1... Attention! One week to the paper deadline ]] [[ Attention! Registration is open! Please have a look at http://www.tcl.tk/community/tcl2016/register.html ]] [[ Known Speakers -- Tutorials * Clif Flynt - GUI Testing with tktest Introduction to Tcl 1 Introduction to Tcl 2 Tcl on Android * Joe Mistachkin - Advanced Windows Integration with Eagle, Garuda, and Harpy * Sean Woods - Advanced TclOO & Megawidgets in TclOO Building Tcl Extensions Fun with CoRoutines ]] Important Dates: Abstracts and proposals due September 12, 2016 Notification to authors September 19, 2016 WIP and BOF reservations open August 22, 2016 Hotel Room ReleaseOctober 22, 2016 Author materials due October 24, 2016 Tutorials Start November 14, 2016 Conference starts November 16, 2016 Email Contact:tclconfere...@googlegroups.com Submission of Summaries Tcl/Tk 2016 will be held in Houston, Texas, USA from November 14, 2016 to November 18, 2016. The program committee is asking for papers and presentation proposals from anyone using or developing with Tcl/Tk (and extensions). Past conferences have seen submissions covering a wide variety of topics including: * Scientific and engineering applications * Industrial controls * Distributed applications and Network Managment * Object oriented extensions to Tcl/Tk * New widgets for Tk * Simulation and application steering with Tcl/Tk * Tcl/Tk-centric operating environments * Tcl/Tk on small and embedded devices * Medical applications and visualization * Use of different programming paradigms in Tcl/Tk and proposals for new directions. * New areas of exploration for the Tcl/Tk language Note: We are especially interested in papers for OS X this time, to complement the keynote. Submissions should consist of an abstract of about 100 words and a summary of not more than two pages, and should be sent as plain text to tclconfere...@googlegroups.com no later than September 12, 2016. Authors of accepted abstracts will have until October 24, 2016 to submit their final paper for the inclusion in the conference proceedings. The proceedings will be made available on digital media, so extra materials such as presentation slides, code examples, code for extensions etc. are encouraged. Printed proceedings will be produced as an on-demand book at lulu.com The authors will have 30 minutes to present their paper at the conference. The program committee will review and evaluate papers according to the following criteria: * Quantity and quality of novel content * Relevance and interest to the Tcl/Tk community * Suitability of content for presentation at the conference Proposals may report on commercial or non-commercial systems, but those with only blatant marketing content will not be accepted. Application and experience papers need to strike a balance between background on the application domain and the relevance of Tcl/Tk to the application. Application and experience papers should clearly explain how the application or experience illustrates a novel use of Tcl/Tk, and what lessons the Tcl/Tk community can derive from the application or experience to apply to their own development efforts. Papers accompanied by non-disclosure agreements will be returned to the author(s) unread. All submissions are held in the highest confidentiality prior to publication in the Proceedings, both as a matter of policy and in accord with the U. S. Copyright Act of 1976. The primary author for each accepted paper will receive registration to the Technical Sessions portion of the conference at a reduced rate. Other Forms of Participation The program committee also welcomes proposals for panel discussions of up to 90 minutes. Proposals should include a list of confirmed panelists, a title and format, and a panel description with position statements from each panelist. Panels should have no more than four speakers, including the panel moderator, and should allow time for substantial interaction with attendees. Panels are not presentations of related research papers. Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather sessions (BOFs) are available on a first-come, first-served basis starting in August 22, 2016. Specific instructions for reserving WIP and BOF time slots will be provided in the registration information available in August 22, 2016. Some WIP and BOF time slots will be held open for on-site reservation. All attendees with an interesting work in progress should consider reserving a WIP slot. Registration Information More information on the conference is available the
Re: [fossil-users] Incremental import breaks repo.
Hello, I've tried the trick with marking explicitly parent of incrementally imported changes line, but this does not work fully. First of all, it definitely helps with the timeline, I can see both or all independent lines of incremental imports nicely connected together. I can also see just one resulting leaf, but on update of checkout from such repository fossil fails and removes all files which were not touched by the last incremental import line. I'm attaching tarball of 3 scripts which clearly shows the behavior and may be used to duplicate/debug it. Put it into some directory and run ./test.sh -- also please modify reconnect.sh first and if your GNU grep is "grep" then please rename "ggrep" to "grep". The scripts were developed on my Solaris workstation where GNU grep is ggrep. Thanks! Karel On Sat, Sep 3, 2016 at 8:26 PM, Karel Gardaswrote: > On Fri, Sep 2, 2016 at 8:28 PM, Svyatoslav Mishyn > wrote: >> Maybe `fossil reparent` and then `fossil leaves --recompute` will help.. >> > > Great! This is indeed working as long as there is acceptable to have > additional artifacts -- are those tags? My testing timeline shows > this: > > $ fossil timeline > === 2016-09-03 === > 17:06:00 [4250222b71] Edit [36f4b3ef8d4a245d|36f4b3ef8d]: Add "parent" > with value "71ffe7ef09c0c3d6e05cd6d31b43e2850586323c". (user: karel) > 17:05:12 [533d224a5c] *CURRENT* change 15 (user: > karel.gar...@centrum.cz tags: trunk) > 17:05:11 [5be7e9c3a3] change 14 (user: karel.gar...@centrum.cz tags: trunk) > 17:05:09 [9ffa7c82c9] change 13 (user: karel.gar...@centrum.cz tags: trunk) > 17:05:08 [1f98a7fe09] change 12 (user: karel.gar...@centrum.cz tags: trunk) > 17:05:07 [36f4b3ef8d] change 11 (user: karel.gar...@centrum.cz tags: trunk) > 17:04:08 [fb6393d303] Edit [6abd71f3a3f2dba4|6abd71f3a3]: Add "parent" > with value "2c3bd124e4733718b448835fe9a8767b0bce9067". (user: karel) > 14:30:14 [71ffe7ef09] change 10 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:13 [d8a49f0142] change 9 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:12 [e17627bb9e] change 8 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:11 [5d3ddbd363] change 7 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:10 [6abd71f3a3] change 6 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:09 [2c3bd124e4] change 5 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:08 [a139dda296] change 4 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:07 [da50998d5f] change 3 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:06 [7f46e6e37d] change 2 (user: karel.gar...@centrum.cz tags: trunk) > 14:30:05 [acfb6b6234] change 1 (user: karel.gar...@centrum.cz tags: trunk) > +++ no more data (17) +++ > > > The question is if the process may be somehow automated or even part > of incremental git import? I'm asking since usually the situation > looks as: > > karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$ > fossil timeline > === 2016-09-03 === > 18:15:39 [30a3929a48] change 10 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:38 [db0ddbb9ba] change 9 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:37 [aa40441d2d] change 8 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:36 [302c071b45] change 7 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:35 [2b36d21f54] change 6 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:33 [8a8dfe4da6] *CURRENT* change 5 (user: > karel.gar...@centrum.cz tags: trunk) > 18:15:32 [7848d4ba85] change 4 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:31 [ca027158d7] change 3 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:30 [92626573e1] change 2 (user: karel.gar...@centrum.cz tags: trunk) > 18:15:29 [bac45c9453] change 1 (user: karel.gar...@centrum.cz tags: trunk) > +++ no more data (10) +++ > karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$ > fossil leaves >(1) 2016-09-03 18:15:39 [30a3929a48] change 10 (user: > karel.gar...@centrum.cz tags: trunk) >(2) 2016-09-03 18:15:33 [8a8dfe4da6] change 5 (user: > karel.gar...@centrum.cz tags: trunk) > > > > this is after one import git -> fossil and after additional > incremental import git -> fossil. Now I would need to connect > 8a8dfe4da6 and 2b36d21f54 together by: > > karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$ > fossil reparent 2b36d21f54 8a8dfe4da6 > karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$ > fossil leaves --recompute > > and after that I'm able to fossil update and be on the same tree like > in git. However such approach is not too comfortable for running > something like git to fossil mirror on OpenBSD's src repository in > automatic manner since this requires user intervention of finding > changes which need to be reconnected. I can probably write some script > or simple program which would parse fossil timeline output and do > that, but the question is if there is more easier way how to find > "root" revision
Re: [fossil-users] Unversioned files.
On 09/05/2016 03:00 AM, Gour wrote: [snip] > Now, when I got rid of ownCloud and replaced it with something lighter > to sync my calendars/contacts with the phone, I plan to manually cp-ing > media files to my computer and considering to put all those > photos/videos as unversioned files in a Fossil repo. > > I use 64bit Linux (Debian Sid) with XFS filesystem, so wonder if there > are any recommended limit in regard to number of files kep in the repo > and/or size of the Fossil repo? I'm not a software developer so my technical insight into these issues might be dangerously insufficient in some places but a couple of data points gleaned from the web might be relevant to the discussion. (bottom of the page) The two issues that stand out [to me] are: A. The Fossil repository might have a maximum size for any single [check-in] file of around 1 or 2 GB ([2] "Maximum length of a string or BLOB"). B. I suspect the storage requirement will be twice (2x) the data size - the data is stored once in the Fossil database and another copy would exist in the file-system [as a check-out]. In a situation where many large files are being managed, those two issues might become significant. I can imagine broad classes of applications within various scientific endeavors where there could be easily ~5TB of instrumentation data in ~10,000 files. Current technology makes this very cost effective. While the measurement data would probably need to be considered immutable, the file metadata, annotations, analysis scripts, commentary, discussion, issues, etc. would probably undergo heavy edits/revisions. (It would be valuable if there were audit trails within the file management/data-sharing system (i.e., file integrity checks with chain-of-custody-like verification)). Fossil almost does everything that is needed to become a killer app for people who need a consolidated [and comprehensible] method/tool to manage, share, and collaborate around a common data-set (e.g., research groups in university laboratories). There are a couple of other capabilities that would extend the use-case/user-base even further but I suspect I am already too far off the reservation for general toleration. [1]: http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/ch02s04.html -- 2.4. XFS Limits 32 bit Linux Maximum File Size = 16TB (O_LARGEFILE) Maximum Filesystem Size = 16TB 64 bit Linux Maximum File Size = 9 Million TB = 9 ExaB Maximum Filesystem Size = 18 Million TB = 18 ExaB -- And [2]: https://sqlite.org/limits.html -- Maximum length of a string or BLOB The maximum number of bytes in a string or BLOB in SQLite is defined by the preprocessor macro SQLITE_MAX_LENGTH. The default value of this macro is 1 billion (1 thousand million or 1,000,000,000). You can raise or lower this value at compile-time using a command-line option like this: -DSQLITE_MAX_LENGTH=123456789 The current implementation will only support a string or BLOB length up to 231-1 or 2147483647. And some built-in functions such as hex() might fail well before that point. In security-sensitive applications it is best not to try to increase the maximum string and blob length. In fact, you might do well to lower the maximum string and blob length to something more in the range of a few million if that is possible. -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Unversioned files.
On Fri, 2 Sep 2016 13:05:43 -0400 Richard Hippwrote: > At the moment, unversioned files are not part of the check-out. So > this is a feature. OK. Thank you. Now, when I got rid of ownCloud and replaced it with something lighter to sync my calendars/contacts with the phone, I plan to manually cp-ing media files to my computer and considering to put all those photos/videos as unversioned files in a Fossil repo. I use 64bit Linux (Debian Sid) with XFS filesystem, so wonder if there are any recommended limit in regard to number of files kep in the repo and/or size of the Fossil repo? Sincerely, Gour -- It is far better to discharge one's prescribed duties, even though faultily, than another's duties perfectly. Destruction in the course of performing one's own duty is better than engaging in another's duties, for to follow another's path is dangerous. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users