Hello,
There is one thing I hate a lot : answering stupid questions. It makes me loose
my time and I certainly do not like that !
The problem is that slack-get is asking stupid questions ! Take the
dependencies tracking for example :
Even if it find a package with the exact name you requested it propose to you
all the matching results.
And one other thing I really don't like in slack-get (and maybe in other
package manager) is that if it find the same package on more than one media it
asks you to choose one.
I do not like that because it is typically something which can be decided by
software itself. If I talk about slack-get, there is a simple way to prefer one
media to another : you have to fill a <official-media>
tag in the configuration file ! I mean, it is an obvious way to prefer this
official media and not bother user asking him if he prefer to install amarok
from Slackware's official servers or from linuxpackages.
But since, yuo can actually prefer this I added a new feature to the media
system : a ranking system.
You can now add a <rank> tag in the medias.xml file
(inside a <media></media> group), with an integer
inside. Since it is a rank, the smaller the number is the highest priority the
media get.
In a near futur (this week at most), I will implements the following new
decision algorithm in the dependencies tracking and package
installation/upgrade systems :
- if there is more than one result for a package check :
- check if there is packages with their name
exactly equal to the request select them
- if their is more than one package like that
(name == request) :
- check if the medias
use ranks
- if yes, then select the package with the highest rank (the smaller number
inside <rank></rank>)
- if not, check if the official-media have the requested
package
- if yes, select the package
- if not, ask user to choose a package
- else if there is only one, select this
package
- else (there is no package where name ==
request), ask user to choose between the original search results.
- else (there is only one response) select the package.
I think this algorithm, will help to not stupidly bother users by asking
unnecessary questions. And since I am fully aware that some users will not like
this automated thing, I will also add a configuration key and a command line
option to allow them to enable/disable this system.
That's all for today !
See ya' for the slack-get development diary #8.
Arnaud Dupuis
slack-get
slack-get is a tool to maintain Slackware GNU/Linux distros
up-to-date.
It feature a daemon, a CLI tool and a Qt4 GUI.
This site is the new slack-get's official website.
Tuesday 9 September 2008
Another new feature in slack-get media system
By Arnaud Dupuis on Tuesday 9 September 2008, 10:35
Friday 5 September 2008
Another huge bug discovered and fixed in slack-get !!
By Arnaud Dupuis on Friday 5 September 2008, 19:06
Hi,
Today I was going to improve (let's say "finish") the dependency tracking system, which is not good enough yet, and I ran into something very very bad...
Before doing anything with the package system, I all the time modify my medias.xml and add a local repository wich contains only one package and it's dependency tree.
Doing this I found a pretty importantly bad bug. This one is described on the slack-get bugtracking system on Sourceforge.
In one word the Slackware::Slackget::Connection's drivers system was completly bugged and had a very important namespace corruption wich was leading to a massive code malfunction.
So far, I strongly recommend to update your local SVN copy.
Fortunatly I fixed this in the latest SVN revision (198).
I hope that I will not found any other surprises like this one !
Arnaud Dupuis
Today I was going to improve (let's say "finish") the dependency tracking system, which is not good enough yet, and I ran into something very very bad...
Before doing anything with the package system, I all the time modify my medias.xml and add a local repository wich contains only one package and it's dependency tree.
Doing this I found a pretty importantly bad bug. This one is described on the slack-get bugtracking system on Sourceforge.
In one word the Slackware::Slackget::Connection's drivers system was completly bugged and had a very important namespace corruption wich was leading to a massive code malfunction.
So far, I strongly recommend to update your local SVN copy.
Fortunatly I fixed this in the latest SVN revision (198).
I hope that I will not found any other surprises like this one !
Arnaud Dupuis
Saturday 30 August 2008
slack-get user interface: step 1, how I see the futur
By Arnaud Dupuis on Saturday 30 August 2008, 00:43
Hi,
I starts coding a little widget (Slackget::QSimpleUpdate). This one looks like that :
I am interested in any opinion/advice/suggestion concerning this. The code of this proof-of-concept is available on the SVN (in trunk/src/QSimpleUpdate/). I made it themable thanks to Qt4 support of CSS.
So far, I think it is a quite fine dock application. I wanted it to be simple to get working, and I also wanted that this widget is able to display enough informations.
That's all for today
Arnaud Dupuis
as I already said I am currently developping the C++ API of slack-get. I also wrote that I am concentrating on usefull part of the API, skipping the generative parts that are not absolutly required at the moment. So in parallel to this development, I made some tests for the graphical user interface. I came up with the conclusion that there is 2 different way to use slack-get :
- Keep a Slackware box up-to-date by installing security fixes and Slackware patches
- Keep a box up-to-date, upgrade and install packages (but not patches)
I starts coding a little widget (Slackget::QSimpleUpdate). This one looks like that :
I am interested in any opinion/advice/suggestion concerning this. The code of this proof-of-concept is available on the SVN (in trunk/src/QSimpleUpdate/). I made it themable thanks to Qt4 support of CSS.
So far, I think it is a quite fine dock application. I wanted it to be simple to get working, and I also wanted that this widget is able to display enough informations.
That's all for today
Arnaud Dupuis
Sunday 27 July 2008
Back online and work resuming !
By Arnaud Dupuis on Sunday 27 July 2008, 12:27
Hi all !
I'm back from Japan and back online !!
I resumed the work on slack-get, and yet added an option to the slack-get client program.
A while ago I thought about some kind of mechanism to display more accurate search results.
Like everybody before myself, I came with a score system where result are evaluated by not-so-simple rules.
As a result each package (I mean Slackware::Slackget::Package) returned by the daemon (sg_daemon) contains a little more data and particularly have a "score" number.
This score wasn't use until today. It's now possible to limit the displayed search results.
For exemple :
slack-get --mid-score search lives
Will display only result with a score greater or equal to 10. Score values can be infinite but most of the time they are under 50.
From what I experienced they are going from 0 to 50. the lesser the score the lesser the probability for he result to be accurate.
By default, slack-get now skip all result with a score under 5.
Well that's not a big improvement, and I still need to write the code for dependencies tracking, but hey ! I'm back to work
Arnaud Dupuis
I'm back from Japan and back online !!
I resumed the work on slack-get, and yet added an option to the slack-get client program.
A while ago I thought about some kind of mechanism to display more accurate search results.
Like everybody before myself, I came with a score system where result are evaluated by not-so-simple rules.
As a result each package (I mean Slackware::Slackget::Package) returned by the daemon (sg_daemon) contains a little more data and particularly have a "score" number.
This score wasn't use until today. It's now possible to limit the displayed search results.
For exemple :
slack-get --mid-score search lives
Will display only result with a score greater or equal to 10. Score values can be infinite but most of the time they are under 50.
From what I experienced they are going from 0 to 50. the lesser the score the lesser the probability for he result to be accurate.
By default, slack-get now skip all result with a score under 5.
Well that's not a big improvement, and I still need to write the code for dependencies tracking, but hey ! I'm back to work
Arnaud Dupuis
Friday 7 March 2008
Release: Slackware::Slackget - Main Perl library for the slack-get package manager - v0.16
By Arnaud Dupuis on Friday 7 March 2008, 12:20
Hi,
The new version of the Slackware::Slackget Perl module have just been released on CPAN.
This 0.16 version add more unit tests to the test suite, should fix the incompatibility problems on Solaris, and fix some bugs in the API.
Particularly, in the Slackware::Slackget::File and in Slackware::Slackget::List classes.
Next changes in the API will be to add Java like iterators to the Slackware::Slackget::List class.
You can download this module on CPAN.
Arnaud Dupuis
The new version of the Slackware::Slackget Perl module have just been released on CPAN.
This 0.16 version add more unit tests to the test suite, should fix the incompatibility problems on Solaris, and fix some bugs in the API.
Particularly, in the Slackware::Slackget::File and in Slackware::Slackget::List classes.
Next changes in the API will be to add Java like iterators to the Slackware::Slackget::List class.
You can download this module on CPAN.
Arnaud Dupuis
Monday 4 February 2008
Websites and (bothering) stuffs like that (bis repetita)
By Arnaud Dupuis on Monday 4 February 2008, 14:17
Hi,
Err, I think it was quite a bad idea to automatically import all article from this blog to http://slackget.infinityperl.org... Since the massive amount of new articles may have made slackget.infinityperl looks like exactly the same than the blog... and Google do not like that at all...
I'm so bad with referencing and stuff like that
If someone have advice on this point, feel free to contact me at (suppress all underscores) a_[dot]_d_u_p_u_i_s_[at]_i_n_f_i_n_i_t_y_p_e_r_l_[dot]_o_r_g
Bye.
Arnaud Dupuis
Err, I think it was quite a bad idea to automatically import all article from this blog to http://slackget.infinityperl.org... Since the massive amount of new articles may have made slackget.infinityperl looks like exactly the same than the blog... and Google do not like that at all...
I'm so bad with referencing and stuff like that
If someone have advice on this point, feel free to contact me at (suppress all underscores) a_[dot]_d_u_p_u_i_s_[at]_i_n_f_i_n_i_t_y_p_e_r_l_[dot]_o_r_g
Bye.
Arnaud Dupuis
Sunday 3 February 2008
Websites and (bothering) stuffs like that
By Arnaud Dupuis on Sunday 3 February 2008, 17:14
Hi,
As you could have figured I'm not really fond of website designing and stuffs like that...
But, in order to have some visibility on the Internet, this is my needed curse.
I intended to send http://slackget.infinityperl.org to oblivion but I realized that it was not really a good idea regarding google's stats.
So to fool the <insert your favorite search engine here>bot, I wrote a script (which is now running with cron), to automatically import all the post I do on this blog, and to do a static export in html from the blog to slackget.infinityperl.org.
I just wanted to keep you aware that you could read two times the same post
Just a little reminder about slack-get project websites :
Official web site : this blog
Old website : http://slackget.infinityperl.org
Web SVN interface : http://slack-get-10.svn.sourceforge.net/viewvc/slack-get-10/
Sourceforge page : https://sourceforge.net/projects/slack-get-10/
Freshmeat page : http://freshmeat.net/projects/ipslackget/
Arnaud Dupuis
As you could have figured I'm not really fond of website designing and stuffs like that...
But, in order to have some visibility on the Internet, this is my needed curse.
I intended to send http://slackget.infinityperl.org to oblivion but I realized that it was not really a good idea regarding google's stats.
So to fool the <insert your favorite search engine here>bot, I wrote a script (which is now running with cron), to automatically import all the post I do on this blog, and to do a static export in html from the blog to slackget.infinityperl.org.
I just wanted to keep you aware that you could read two times the same post
Just a little reminder about slack-get project websites :
Official web site : this blog
Old website : http://slackget.infinityperl.org
Web SVN interface : http://slack-get-10.svn.sourceforge.net/viewvc/slack-get-10/
Sourceforge page : https://sourceforge.net/projects/slack-get-10/
Freshmeat page : http://freshmeat.net/projects/ipslackget/
Arnaud Dupuis
Saturday 2 February 2008
SGNCC - Slack-Get Naming Convention Compliant : the new slack-get's naming convention document
By Arnaud Dupuis on Saturday 2 February 2008, 17:35
Document purpose :
The purpose of this document is to "standardize" slack-get development by imposing a naming convention for both (but not only) : slack-get clients, sg_daemon, all Perl modules and the C++ library.This include of course, all plug-in which can be released in the futur.
Vocabulary :
In the future, we will refers to the slack-get naming convention as :SGNC: for Slack-Get Naming Convention.
Additionally, we will refers to SGNC compliant code as SGNCC (SGNC Compliant).
Scope of the SGNC :
All the code released under the "slack-get development team" label must be SGNC compliant (SGNCC).More generally, all code released and packaged with slack-get must be (and will be) SGNCC.
The SGNC apply to all API visible method names. Every methods in a class or bundle must be SGNCC. By extension to this principle all methods in the sg_daemon, slack-get and the upcoming slack-get GUI have to be SGNCC.
All script released and packaged with slack-get should be SGNCC too. But in order to not slow down some developments it is acceptable to keep not SGNCC code in the branch/ SVN tree. If released with slack-get, this code will be optional at building and installation time. It will also be released in a different package.
Rules of SGNC :
We refer to functions and methods as the same generic term of "method".The SGNC consist in the following 3 simple programing rules :
- a method name consist of lower case, English words where space are replaced with underscores ;
- if the method name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper case.
- if a conflict was solved according to rule 2), and if the name conflicts with only one of the supported languages (Perl and C++), add a wrapper method around the renamed one, in order to comply with the rule 1).
The slack-get development team
Wednesday 30 January 2008
slack-get API review
By Arnaud Dupuis on Wednesday 30 January 2008, 08:39
Hi,
Back from holidays, I started to work again on slack-get by a huge code review and documentation updates of the API.
My current contract had an impact on this process since it consists in extending the NMIS tool. This tool is really great and useful like no other ones when it comes to network monitoring tasks.
But this tool also have an important flaw : its API is a real mess. It consist of a main script of 7000 code lines and few modules (around 10) totally undocumented !
My job is currently to run into this code, understand it (hopefully it's not too hard to guess) and find a way to add something like a plug-in system to it. Unfortunately, all NMIS modules exports all their functions in the calling script's namespace...
So I choose to have a different naming convention than the one in NMIS for plug-in's methods name... And their is no naming convention in NMIS...
And I sadly saw that it was exactly the same with slack-get Perl API... So starting today I will change that and tag along with the following naming convention :
Arnaud Dupuis
Back from holidays, I started to work again on slack-get by a huge code review and documentation updates of the API.
My current contract had an impact on this process since it consists in extending the NMIS tool. This tool is really great and useful like no other ones when it comes to network monitoring tasks.
But this tool also have an important flaw : its API is a real mess. It consist of a main script of 7000 code lines and few modules (around 10) totally undocumented !
My job is currently to run into this code, understand it (hopefully it's not too hard to guess) and find a way to add something like a plug-in system to it. Unfortunately, all NMIS modules exports all their functions in the calling script's namespace...
So I choose to have a different naming convention than the one in NMIS for plug-in's methods name... And their is no naming convention in NMIS...
And I sadly saw that it was exactly the same with slack-get Perl API... So starting today I will change that and tag along with the following naming convention :
- a method name consist of English words where space are replaced with underscores ;
- if the name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper case.
- if a conflict was solved according to rule 2), and if the name do not conflict with the other language, add a wrapper method around the renamed one, in order to comply with the rule 1).
Arnaud Dupuis
Thursday 10 January 2008
Little question from a slack-get user
By Arnaud Dupuis on Thursday 10 January 2008, 09:52
Hello,
I recently received an email from Mark, a slack-get user, who asked me a very simple question : why have I called slack-get this way ?
Well, this is a tricky question. Let me answer this :
At first I wanted to call it get-slack, this is the name of the menu you have to click on Slackware's website. But it was to close from the website and I didn't want to take this initiative (at least not alone, I could have ask for the permission of Pat or the crew). So helped by a huge sense of originaluty and creation, I decided to switch syllable and/or letters.
I came with some nice thing like : gsletack or gstckael but I was afraid somebody else already took the name (and a bit afraid about the poor americans unable to pronounce that ... not talking about Japanese... and not talking about me !).
So I finally came with slack-get, a bit inspired (i must admit it) by an obscur soft called apt-get, and largelly because of the signification of slack-get's acronyme :
So, Mark, I hope that I answered your question Else feel free to send me
another email (I like receving email from slack-get users, particularly when
they are kind with me and slack-get !).
See you later,
Arnaud Dupuis
I recently received an email from Mark, a slack-get user, who asked me a very simple question : why have I called slack-get this way ?
Well, this is a tricky question. Let me answer this :
At first I wanted to call it get-slack, this is the name of the menu you have to click on Slackware's website. But it was to close from the website and I didn't want to take this initiative (at least not alone, I could have ask for the permission of Pat or the crew). So helped by a huge sense of originaluty and creation, I decided to switch syllable and/or letters.
I came with some nice thing like : gsletack or gstckael but I was afraid somebody else already took the name (and a bit afraid about the poor americans unable to pronounce that ... not talking about Japanese... and not talking about me !).
So I finally came with slack-get, a bit inspired (i must admit it) by an obscur soft called apt-get, and largelly because of the signification of slack-get's acronyme :
So, Mark, I hope that I answered your question
Else feel free to send me
another email (I like receving email from slack-get users, particularly when
they are kind with me and slack-get !).See you later,
Arnaud Dupuis
Wednesday 19 December 2007
"slack-get update" command on the way !
By Arnaud Dupuis on Wednesday 19 December 2007, 07:26
Hi,
Just to keep you up-to-date, the "slack-get remove <packages list>" command now works correctly (although I still need to do tons of testing) and the "slack-get update" command is on the good way.
Once it will be finished, the "slack-get upgrade <packages list>" will also be ready because both of those commands are closely bounded.
The difference between the two commands is pretty simple :
while the "upgrade" one allow you to upgrade (download + upgradepkg) a named list of packages, the "update" command check for all updates available in <repository root>/patches/packages/.
On a freshly installed Slackware 12.0 you get the following output (click on the image to enlarge it) :
That's all for today. See you later for the development diary.
Arnaud Dupuis.
Just to keep you up-to-date, the "slack-get remove <packages list>" command now works correctly (although I still need to do tons of testing) and the "slack-get update" command is on the good way.
Once it will be finished, the "slack-get upgrade <packages list>" will also be ready because both of those commands are closely bounded.
The difference between the two commands is pretty simple :
while the "upgrade" one allow you to upgrade (download + upgradepkg) a named list of packages, the "update" command check for all updates available in <repository root>/patches/packages/.
On a freshly installed Slackware 12.0 you get the following output (click on the image to enlarge it) :
That's all for today. See you later for the development diary.
Arnaud Dupuis.
Tuesday 27 November 2007
New Network backend mechanism
By Arnaud Dupuis on Tuesday 27 November 2007, 21:32
Today I implemented the new slackget10::Network mechanism I wanted to. What is
it you ask ?
Clearly something which will help everything to be super-easy to improve. As you may know (or not) the slackget10::Network Perl Module has been completely redesigned and will be largely recoded.
The changes are quite important and the API is completely new. It's now a front end module (like slackget10::Network::Connection is) and it aim at providing a unified interface for all kind of "protocol" implementation.
The idea is to answer the question : "what are you doing with an incoming network packet ?". The answer is simple : you decode it, you interpret it, you build the answer and you encode the answer before sending it.
Clearly something which will help everything to be super-easy to improve. As you may know (or not) the slackget10::Network Perl Module has been completely redesigned and will be largely recoded.
The changes are quite important and the API is completely new. It's now a front end module (like slackget10::Network::Connection is) and it aim at providing a unified interface for all kind of "protocol" implementation.
The idea is to answer the question : "what are you doing with an incoming network packet ?". The answer is simple : you decode it, you interpret it, you build the answer and you encode the answer before sending it.
Saturday 10 November 2007
Week end planning
By Arnaud Dupuis on Saturday 10 November 2007, 15:46
Hi ,
I'm working a lot on slack-get this week end ! Today's morning was concentrated on slackget10::Network::Connection modifications. I made quite a lot of them. I made two major changes in the module architecture :
- I made the protocol driver's loading completly dynamic (no more static, hardcoded hash table to track authorized protocols)
- I changed all drivers (slackget10::Network::Connection::*) and made them independents from the slackget10::Config. The "config" parameter is not required anymore. In place of this option you have to give the "download_directory".
I also updates the Wiki by creating some API documentation pages.
Let's keep the pace !
Arnaud Dupuis
Wednesday 24 October 2007
new release of the slack-get Perl Module - slackget10-0.10
By Arnaud Dupuis on Wednesday 24 October 2007, 06:50
Hi all !
After doubt and interrogation, even after I though to dismiss the slack-et project it couldn't be helped... I enjoy developing this tool !
So be it. Here is the latest release of the slack-get Perl Module. Tons of thing are new since there was a not-released version...
This release main features are :
- loads of bugfixes (starting with the test suite)
- removed unused modules
- removed deprecated modules
I'm now working on the slack-get communication protocol. This protocol is full XML based and have to be well designed to support all situation of usage.
It also have to be bulletproof and highly error resistant.
By the way the slack-get devel mailing list have open, please find more information on this at Sourceforge , you can also find more informations about slack-get SVN on Sourceforge.
You can find all documentation and source of the new version of slackget10 on CPAN
That's all for the moment.
Good day
Arnaud Dupuis
Saturday 8 September 2007
slack-getd is dead, long live sg_daemon !
By Arnaud Dupuis on Saturday 8 September 2007, 13:35
It's now official : slack-getd is dead. There is a lot of (good) reasons for me to do so :
- The network protocol is not totally unified. Part is plain-text based and part is XML based.
- While recoding slack-getd to create a fully event driven daemon I saw some important part of the code which couldn't be moved easily from the old behaviour to the new event based one.
- Extending slack-getd possibilities is not that easy to do with the current implementation.
In the end sg_daemon will include the following features :
- a fully event driven code
- a full XML network protocol
- an easy to maintain and easy to extends code
I do hope to release the first working version soon (within the month). Obviously if the network protocol change it will no longer works with the current GUI.
But I'll try to add some compatibility code, at least for the RC1 version.
All this things obviously change the scheduled release plan, and I'll release more release candidates for the 1.0.0-alpha branch than initially planned.
Arnaud DUPUIS
