SliTaz Forum
You are not logged in.
Nimrod is a programming language, and I like it! 
A few days ago in the #slitaz IRC channel I hear what @Trixar_za talk to @ccssnet, that it's not a bad idea to rewrite TazPkg using some of compiling language, possible Nimrod. In that momemnt I not hear this name before. But next day I downloaded Nimrod sources, GCC and all what I need, I compiled compiler and bootstrap, and I set down at white Geany's paper to write my first program.
Development process for me is the same as Shell code programming:
[*]I define task (rewrite only hard timed loops in TazPanel, not in TazPkg);
[*]I open Geany as text editor;
[*]I open Midori with Nimrod's docs;
[*]I open Sakura to compile source.
That day I wrote several lines of code, but no joy. I've trapped in dead end of lack of examples.
Next day (or two) I read docs, I find big amount of great commands, and I write and rewrite my code, and I think it very nice now
At the time I implemented two main TazPanel/pkgs loops: list of MyPackages, and cat of all mirror's packages by category. To compare execution time, I've cutting shell code loops to separate test scripts, you can find them in attachments. Execution time depends on CPU, I have "2x Intel® Atom™ CPU N270 @ 1.60GHz". Here are results:
[attachment=11900,560]
Do you want to have a system that works in from 10 to 500 times faster? Silly question! YESSS! 
I prepare a handmade package for you (due to forum restrictions, please remove last ".zip" from package's name), and you can easy install it to your system and test it's speed and performance. But I want to say you that this is only Developer's preview, it can be broken, and I recommend you to return to stable TazPanel version after all experiments ends. But you can stay with it.
Anyway, enjoy! Now you know what is "Fast as SliTaz" ;D
The heart of new possibilities is /usr/bin/tazpanel_inc (37,6KiB). Not so small, but it statically linked (standalone) and not wanted any external libraries to run. And size of resulted binary increased slowly.
And, at the end I want to raise a question: what is a future of this code? Are here developers who have free time and who interested in rewriting TazPanel, TazPkg and other SliTaz tools in Nimrod? We can collaborate. Or we leave this Nimrod code includes as-is? Or...?
Offline
Hi Aleksej,
Nice job.
=> " (due to forum restrictions, please remove last ".zip" from package's name),"
There is no more forum restrictions for .tazpkg files.
Offline
It has a slight bug in it that makes it crash at around the d's. Not that I haven't seen it before. Sometimes optimizing can break the Nimrod program too - I've seen that for Aporia.
[attachment=11965,564]
That reminds me, I should package Aporia. It's a pretty good beaver replacement and is written in Nimrod. It's also lighter, smaller and faster than Geany or Beaver. It even has syntax highlighting and auto-completion for Nimrod, which is a help.
EDIT: This will probably be a more helpful error:
Traceback (most recent call last) tazpanel_inc.nim(122) tazpanel_inc tazpanel_inc.nim(90) cat Error: unhandled exception: index out of bounds [EInvalidIndex]
Offline
Oh, I forget to say. We have bug not in my code, but in packages.desc!
Aha.
Line with "e3" breaks occasionally into two lines. Recently I think that it only my packages.desk error and corrected it by hands in mc.
Offline
Yeah, but it happens in other categories too. For example it stops dead at dwm under the x-window category
Offline
Correct: open /var/lib/tazpkg/packages.desc and search for "e3", remove LF between "NASM" and "assembler".
Ok, anyway I need more "boilerplate" code ;/
I can only one — ignore incomplete strings. Any other ideas?
e2fsprogs-dev | 1.41.14 | The e2fsprogs devel files. | development | http://e2fsprogs.sourceforge.net/
[c]pkg_name="e2fsprogs-dev"
version="1.41.14"
short_desc="The e2fsprogs devel files."
category="development"
web_site="http://e2fsprogs.sourceforge.net/"[/c]
e3 | 2.8 | e3 is a full featured text editor written in NASM
[c]pkg_name="e3"
version="2.8"
short_desc="e3 is a full featured text editor written in NASM"
category="? ? ? !? o_O"
web_site="??? x_X"[/c]
assembler. | utilities | http://sites.google.com/site/e3editor
[c]pkg_name="assembler."
version="utilities"
short_desc="http://sites.google.com/site/e3editor"
category="x-P"
web_site="O_o"[/c]
Offline
Yes, that fixed it. My only other idea is to fix packages.desc's generation so bugs like this doesn't creep in
Offline
Additionally I want to fix e3 receipt in the wok — description came from receipt.
http://hg.slitaz.org/wok/file/fc26d61dfefe/e3/receipt
Offline
I see so. A single typo by Pascal and we have a world of trouble. This might also mean trouble for other badly formatted receipts. I removed the debugger in tazpanel_inc (-d:release) and optimized it for speed (--opt:speed) rather than size. It flies on my PC now. I might even use Tazpanel for packages now instead of my usual route of using tazpkg from command line.
Offline
http://hg.slitaz.org/wok/annotate/fc26d61dfefe/e3/receipt
Not Pascal, but devl547
PS: Fixed http://hg.slitaz.org/wok/annotate/9584196b887d/e3/receipt
From my Makefile:
[c]nim:
nimrod c -d:release --opt:size tazpanel_inc.nim
strip -s tazpanel_inc[/c]
[c]make nim[/c] to compile and strip.
I can't see any changes in speed between optimized for speed and optimized for size %)
Offline
Optimizing for speed is slightly faster than optimizing for size from how I just tested it. The binary is double the size if optimized for speed though 
Oh and dom96 would like you to put the source code on github 
Offline
Thanks to dom96! Maybe. But I hardly awkward with git.
Maybe, better for me in bitbucket mercurial repos? (I asking myself)
Offline
Github has a pretty extensive help built in. I learned how to use git through it.
Offline
I would not like to learn yet another tool, in which the barrier to entry is high enough. I just want to program. And I'll be using Mercurial, which I have already more or less learned. Period.
I've created a team account: http://bitbucket.org/slitaznimrod
Who want to join, please, ask me for invite
Offline
http://hg-git.github.com
Also I created http://github.com/SliTaz - but I've been having trouble uploading files. Fun
Offline
@Aleksej, Trixar: Why not use the SliTaz repository ?
Offline
Mostly because I don't really know mercurial well. Araq and dom96 (two of the developers of Nimrod) would also like more Nimrod exposure on Github.
Offline
@erjo, for me it's the same, because I have write permissions to SliTaz Hg. Just I need separate repo in Hg. But I never seen Brenton's commits, does he have access to SliTaz Hg?
Ok, I need separate repo (make it name 'nim-tools'), where will be sub-repo with Nimrod developments (TazPanel, TazPkg, TazPkg-web, etc). I think I will rewrite them as long process with step-by-step implementing (more and more) parts of existing Shell code to Nimrod code, with keeping of work ability at any moment of development.
Btw, today I working with tazpkg-web. And it seems like we have slightly outdated code in our Hg rather than working code on pkgs.slitaz.org. @Pascal?
Offline
As far as re-writing tazpkg goes, why not base the new package manager written in nimrod on spk. We have already cleaned lots of code and broken it up into manageable chunks. I have been going through the nimrod tutorials and love it compared to sh.
Offline
@Aleksej I made like one commit to wok which fixed the ppp issue. I think I did the commit is trixarian or something though.
So yes, I do have hg access, only I rarely use it
Offline
Certainly Nimrod is a great tool, moreover the speed gain when running Tazpkg is amazing, but I'm very reluctant to see Tazpkg rewritten in Nimrod, mainly for philosophical reasons, there are other issues, but I'll stick to philosophical ones.
#1. Most people will lose freedom. Actually Tazpkg is written in Almquist Shell, the main benefit is that almost everybody is allowed to check its source code, understand how it works and maybe (who knows?) send patches to the developpers. If tomorrow, Tazpkg is rewritten in Nimrod, less than a handful of experts will understand how Tazpkg works and behave. All other people will not make the effort to learn Nimrod and instantly lose access to a part of SliTaz and, this is the most important issue, will also lose the freedom to learn, modify, customise SliTaz to fit their own needs.
#2. It's against the SliTaz Kiss philosophy: « Keep it simple: follow the best standards, carefully draft and write high quality documentation, provide a stable and robust system and keep the rootfs on the LiveCD light enough to run on machines with at least 128 MB RAM. It's also possible to use GTK+2, Dialog, SHell scripts, or PHP coding tools on the distribution. » (http://www.slitaz.org/en/devel/forge.php)
#3. Free Software is, like forests, atmosphere, fisheries, grazing lands, rivers, irrigation systems a common resource that is shared, used and enjoyed by all. Some people like late Elinor Ostrom spend their lifetime to define principles to manage commons in a long-term sustainable way. One of these principle is to allow most resource appropriators to participate in the decision-making process. I maybe wrong but I'm afraid it's not the case in the decision to rewrite Tazpkg in Nimrod.
It's just my own opinion, and I'm maybe wrong. I trust you and have great respect for what you do and have done for SliTaz, I just try to honestly express a different opinion without wanting to hurt anyone, please, don't call me Joseph Stalin:)
-- dom
Offline
#1 Nimrod is easy to learn and it can output to C too. Most people pick Nimrod up in about a few days. Bash scripting Language itself requires you to learn it, not to mention the proper usage of awk. The source code will be open like Tazweb. Yet rewriting tazpkg will lose people their freedom? If anything it's no different than aptitude, which gets also released as a binary, but has it's source availiable.
#2 SliTaz KISS philosophy normally applies to the balance between simplicity, size and speed. If we rewrite tazpkg, the interface would be the same and we'll have the speed of a binary. Size should also be about similar. Also it's an acceptable standard to use binaries for package management.
#3 Nimrod and the new tazpkg will be GPL with source avialable that can be freely modified, so it will be free software. Simple as that
Offline
@domcox
As far as learning a new language and code simplicity goes, sh is convoluted and does not emphasize good coding practices (3000+ line tazpkg is a testament to that). It is a good point though and one we should hold in the back of our minds when making decisions like this.
Offline
@Aleksej: If you wish http://hg.slitaz.org/nim-tools/
Offline
Hello!
It seems that I need too to express my opinion to clarify the situation. As I see it.
@domcox , @all:
Probably I am geek. Or, a hacker Most of all I love to program. I don't love anybody so much, how to write good code. Ehh…
And regardless of anyone's opinion, I'll write. And I'm writing now support procedures. Unfortunately, my vacation is over and now I can spend less time programming and project, but work will continue.
This is certainly a fork. Another question is whether it will be official? But it will be.
Our repositories have available regular kernel and kernel-libre. Perhaps we can afford the luxury — to have two versions of our projects? Judging by the initial negative evaluation, they should be called: tazpanel-official-(opensource-libre-kiss), and tazpanel-fork-(closed-evil-binary-blob). Oh, excuse me, I joking Of course, in addition to the binary program itself, will be available the source code. And everyone just be able to contribute to its development.
In the world of Linux and open source is common to write in various programming languages. Write in the language that you prefer. So now we have a lot of great (and not) programs written in C, Python, Perl, PHP, Shell, Java, Mono, and others. We have TazWeb written in C…
It is considered that the language of BASH/Shell is very simple. Even if it is not, then it needs to know every self-respecting Linux users. BASH/Shell is always installed in all systems of Linux. I think that it is suitable for automation of daily activities, for any simple task, as well as for writing the drafts of any algorithms. In the case of heavy-duty cycles, is obtained that the CPU just executes unnecessary work, at a time when the same task could be performed faster and with less energy. How's about the principle of KISS? Perform the task at less cost — is KISS?
Of course, Nimrod is not ideal either for speed or size. The ideal is the assembler — language of the processor, but it is extremely difficult to develop anything. Somewhat better language C, it produces not as fast and not so little code, but it is the industry standard for writing major programs.
I am not a programmer, alas. And I do not want to spend too much time (a year or two?) to learn how to program in C. Nimrod seemed simple enough, and after a few days of my experiments with it, I had quite efficient and damn fast program. I do not consider myself to be too clever, and so I think that anyone who is familiar with programming in any language will be able to learn Nimrod.
@erjo :
Thank you a lot, I'll use this repo. To begin, I want to write a procedures that will be useful in any SliTaz project, for example, now I am writing a procedure for easy application of i18n.
And then, of course, will need to decide what to take first. We can divide. I personally would like to start with pkgs.slitaz.org.
@all:
The probability of receiving assistance in the development is vanishingly small (under 1% rule) regardless of the language in which we write our programs, whether it's Bash, or Nimrod.
But it seems that the three men are willing to continue right now — it's me (Aleksej), Brenton Edgar Scott (Trixar_za) and Christian Mesh (Naitsirhc). Good luck, my friends!
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.59 MiB (Peak: 1.77 MiB) ]