Stuff I've been working on
Yep, I finally got sick of typing the 26 letter domain DistributedInformation.com, so I’ve traded down to 10!
fosiki.com
Still working on TWiki and open source, but also doing other Social Apps, including a few in facebook.
I’ll write about the name’s providence later – perhaps I’ll even be able to make up a long convoluted story 🙂
CPAN, while incredibly useful, can be a pain, if you forget that you need to re-configure it after installing essential tools.
For example, if you make the mistake of setting up a basic, non-development Debian virtual machine, configure CPAN, try to use it, and on seeing ‘make’ errors like (from install Bundle::CPAN of all things) :
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running install for module Compress::Raw::Zlib
Running make for P/PM/PMQS/Compress-Raw-Zlib-2.012.tar.gz
Is already unwrapped into directory /root/.cpan/build/Compress-Raw-Zlib-2.012
Has already been processed within this session
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running make for P/PM/PMQS/IO-Compress-Zlib-2.012.tar.gz
Is already unwrapped into directory /root/.cpan/build/IO-Compress-Zlib-2.012
Has already been processed within this session
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
cpan>
You install make apt-get update ; apt-get install build-essential…, only to continue to see the same errors wizz past….
CPAN really truly needs to realise that the make settings are mis configured, and tell you.
What you need to do, is to tell your cpan about it by running:
cpan> o conf init
OR, if you’ve not yet messed (configured) up your cpan, install build-essential first.
And while you’re contemplating using cpan, think hard about trying dh-make-perl instead 🙂
Ideally, CPAN should be able to realise that it can’t call make if it does not know where it is – and point this fact out, rather than making it appear as though the package being installed has an issue.
I just ran across a pretty annoying issue when updating one of my TWiki’s from 4.2.0 to 4.2.2. The server it is on was running Perl 5.10, but the Encode module was 2.25, resulting in Wysiwyg edits having all their spaces replaced with %20, and line feeds %0A ala
%20Debian%20equivalent%20of%20chkconfig%0A%0A/usr/sbin/update-rc.d%20avahi-daemon%20defaults%0A%0Ahttp%3A//wiki.linuxmce.org/index.php/Hardware%0A
(look familiar Martin? :))
perl -MCPAN -e shell
upgrade Encode
Got me to Encode v2.26, which fixed it for me.
update: Martin’s just confirmed that it didn’t help him on perl 5.8.4, so perhaps its an odd combination of outdated modules?
I’ve just updated the Experimental TWiki and Plugins repository. It now contains TWiki 4.2.2 and 226 Plugins, Contribs and Skins that you can simply apt-get install
To use them, add the following 2 lines to your /etc/apt/sources.list
deb http://distributedinformation.com/experimental/ experimental main contrib
deb-src http://distributedinformation.com/experimental/ experimental main contrib
then type
apt-get update
to update the available packages.
you can now see all 226 packages with apt-cache search twiki-
and install (assuming you don’t have twiki installed yet)
apt-get install apache2 twiki
Now that I’ve added external dependancies to the repository, complex TWiki Plugin like ImageGalleryPlugin is as easy as apt-get install twiki-imagegalleryplugin and then enabling it via configure.
etch:~# apt-get install twiki-imagegalleryplugin
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
defoma gsfonts libfreetype6 libgraphics-magick-perl libgraphicsmagick1 libice6 libjasper-1.701-1 libjpeg62 liblcms1 libmagick9 libpng12-0 libsm6 libtiff4 libwmf0.2-7
libx11-6 libx11-data libxau6 libxdmcp6 libxext6 libxml2 libxt6 perlmagick x11-common
Suggested packages:
defoma-doc psfontmgr x-ttcidfont-conf dfontmgr libfreetype6-dev graphicsmagick-dbg libjasper-runtime liblcms-utils libwmf-bin
Recommended packages:
libft-perl gs-gpl gs xml-core
The following NEW packages will be installed:
defoma gsfonts libfreetype6 libgraphics-magick-perl libgraphicsmagick1 libice6 libjasper-1.701-1 libjpeg62 liblcms1 libmagick9 libpng12-0 libsm6 libtiff4 libwmf0.2-7
libx11-6 libx11-data libxau6 libxdmcp6 libxext6 libxml2 libxt6 perlmagick twiki-imagegalleryplugin x11-common
0 upgraded, 24 newly installed, 0 to remove and 15 not upgraded.
Need to get 11.2MB of archives.
After unpacking 25.4MB of additional disk space will be used.
You will still need to use configure to enable Plugins.
Please report your experiences to me – bugs, gripes, you name it – its a work in progress. and I need your help!
This release makes over 150 improvements to the current Enterprise TWiki.
Along with many WYSIWYG Editing improvements, better UTF8 support, User mapping fixes and SEARCH improvements, This release contains an optimization that should see 4.2.1 being 10-30% faster than 4.2.0.
I will be updating the TWikiInstallers as soon as I can – the Windows installer should see the biggest impact, as I have managed to fix a number of SEARCH issues that are windows specific.
see TWikiRelease04x02x01 for more details.
I’ve just updated the Experimental TWiki and Plugins repository. It now contains TWiki 4.2.0 and 212 Plugins, Contribs and Skins that you can simply apt-get install
To use them, add the following 2 lines to your /etc/apt/sources.list
deb http://distributedinformation.com/experimental/ experimental main contrib
deb-src http://distributedinformation.com/experimental/ experimental main contrib
then type
apt-get update
to update the available packages.
you can now see all 212 packages with apt-cache search twiki-
and install (assuming you don’t have twiki installed yet)
apt-get install apache2 twiki
and TWiki Contrib installation is as easy as
apt-get install twiki-bugscontrib
You will still need to use configure to enable Plugins.
Please report your experiences to me – bugs, gripes, you name it – its a work in progress. and I need your help!
I’ve been using firefox 3 on my notebook since beta3, and loving its lower CPU and memory needs, but have been frustrated by the lack of 64 bit builds for my 8Gig RAM desktop development and VMWare system.
It seems that they have been building 64bit binaries for quite some time – see their nightly build dir.. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
NICE!
(test post using Gnome Webog poster)
The last fortnight, I’ve been working on creating a new, soon to be released to web 2.0 ‘Beta’ site based on TWiki 4.2.0. That means that I’ve been busy finding, reporting and fixing Bugs for TWiki 4.2.1.
The list todate are:
Item5455 BuildContrib doesn’t cope with larger numbers of files Closed 15 Apr 2008 – 04:34 SvenDowideit
Item5536 robots.txt is missing some obvious scripts – like login Waiting for Release 14 Apr 2008 – 08:43 SvenDowideit
Item5535 IF{“$BANNER” does not really work. Waiting for Release 14 Apr 2008 – 06:49 SvenDowideit
Item5534 missing contexts for several bin scripts Waiting for Release 14 Apr 2008 – 06:25 SvenDowideit
Item5533 tmpl login script does not do writeCompletePage, so it does not get addToHEAD bits. Waiting for Release 14 Apr 2008 – 05:10 SvenDowideit
Item5513 update TalkContrib topic Closed 11 Apr 2008 – 06:19 SvenDowideit
Item5509 IF & query String matching may be incorrectly greedy. Waiting for Release 11 Apr 2008 – 01:55 SvenDowideit
Item5501 IF allows does not work correctly if the topic does not exist. Waiting for Release 11 Apr 2008 – 01:41 SvenDowideit
Item5510 initial version of TalkContrib Closed 09 Apr 2008 – 08:11 SvenDowideit
Item5499 TWiki::UI::Resister::changePassword sends login, not cUID to TWiki::Users::setPassword Waiting for Release 04 Apr 2008 – 02:24 SvenDowideit
Item5496 Conclusion: Turn off UTF-8 test case until bug is fixed (4.2 branch only) Waiting for Release 03 Apr 2008 – 02:06 SvenDowideit
Item5495 add twikiBroadcastMessage class div to default & classic skins Waiting for Release 03 Apr 2008 – 00:53 SvenDowideit
These Windows, OSX, Centos and Fedora Core installers are fully integrated native installers that will update your Computer with perl, apache, rcs and other tools needed to run TWiki on that platform.TWiki 4.2.0 contains many new improvements to TWiki, including a much improved Wysiwyg editor, a structured query engine, a more generic authentication system and at the same time, the Core engine is faster than the previous twiki4 releases.The TWiki installers include native installs of (only installed if not already)
Please download it, try it out and report your impressions, ideas, bugs and successes here, on TWiki.org, or in the TWiki Bugs system.
Another TWiki innovation brought to you by distributedINFORMATION & 
WikiRing.com
I’ve been promising myself some time to try out DTrace on TWiki’s codebase for over a year. By following Bryan Allen’s
instructions using Richard Dawe’s adaption of Alan Burlison’s work… I now have a Perl 5.8.8 with DTrace probes.
Sounds great, except for one thing…. I now have to learn enough about DTrace to use it 🙂 The patch that Alan and Richard have (or at least their DTrace scripts) seem to require a priori knowledge of the Perl process’ pid… not something thats going to work out for what I want to do.
For a quick test, DTrace -c ./view -s /export/home/sven/src/dtrace/subs-tree.d does show the program flow.
The following is while running some perl scripts – the 2 numbers are their pids.
# dtrace -l | grep -i perl
17803 perl17669 libperl.so Perl_pp_sort sub-entry
17804 perl17669 libperl.so Perl_pp_dbstate sub-entry
17805 perl17669 libperl.so Perl_pp_entersub sub-entry
17806 perl17669 libperl.so Perl_pp_last sub-return
17807 perl17669 libperl.so Perl_pp_return sub-return
17808 perl17669 libperl.so Perl_dounwind sub-return
17809 perl17669 libperl.so Perl_pp_leavesublv sub-return
17810 perl17669 libperl.so Perl_pp_leavesub sub-return
88501 perl17760 libperl.so Perl_pp_sort sub-entry
88502 perl17760 libperl.so Perl_pp_dbstate sub-entry
88503 perl17760 libperl.so Perl_pp_entersub sub-entry
88504 perl17760 libperl.so Perl_pp_last sub-return
88505 perl17760 libperl.so Perl_pp_return sub-return
88506 perl17760 libperl.so Perl_dounwind sub-return
88507 perl17760 libperl.so Perl_pp_leavesublv sub-return
88508 perl17760 libperl.so Perl_pp_leavesub sub-return
so… first ignorant modification – in subs-tree.d, it wants to trace perl$target:::sub-entry – change that to perl*:::sub-entry, and of course, it works exactly as I want – attaches to all subsequent perl process (running my dtrace-perl build) and tells me whats going on. The only caveat being that the DTrace script will only start if there is a Perl process running – the provider is obviously not persistent.
Brilliant!
Should be a fun Christmas holiday adventure – 410 pages of dtrace book, and a myriad of web pages to consume and digest.