Sammelstelle für Kram des Monats

Hier werden die Vorschläge für den Kram des Monats gesammelt.


Für alle, die jetzt erst eingeschaltet habe gehe ich mal die Regeln durch:
1.) Wir sammeln Vorschläge für interessanten Kram in zwei Kategorien:
a) Biblioheken, Programme, Sprachen und Algorithmen, die man dem Forum mal vorstellen sollte. Kram wie make, getopt, Boost, Eclipse oder Ruby
b) Interessanter Code aus dem Forum. Alles, was hier gemacht wurde und lehrreich oder interessant ist. Achtung: Alle Beiträge in dieser Kategorie müssen im Quelltext vorliegen!
Wenn ihr etwas vorstellt solltet ihr natürlich auch ein paar Zeilen dazu schreiben: Was ist es, was macht es, wo läuft es - und warum ist es für die Forenuser interessant?

2.) Es werden einen Monat lang Vorschläge für den übernächsten Monat gesammelt. Dann wird ein bis zwei Wochen lang abgestimmt, was im nächsten Monat der Kram des Monats wird.

3.) Damit bleiben zwei bis drei Wochen, in denen jemand einen Artikel über den Kram des Monats in der Kategorie a) schreibt - in der Regel der, dessen Vorschlag genommen wurde, er ist der Experte. Außerdem schreibt der Autor des in Kategorie b) gewählten Krams ein bißchen was über seinen Code.

4.) ???

5.) Profit.


Die Details (wie die Dauer der Abstimmung) stehen noch nicht wirklich fest, wir probieren erst mal, ob's klappt. Kommentare bitte in diesen thread.

Ob für jeden Monat ein neuer Sammelthread aufgemacht wird oder wir den einen hier weiterbenutzen wird sich zeigen. Wahrscheinlich benutzen wir aber einen weiter.

Nu macht ma.

Oh Klasse!

Ich hab da auch ein paar Vorschläge, die vielleicht für dein ein oder anderne ganz interessant sein könnten:

• Wie schon gesagt: Eclipse. Die JDT mal vorrangig, allerdings wären die CDT auch eine Erwähnung wert, da es vor allem die erste ernstzunehmende Linux-C-Entwicklungsumgebung ist.
• Concurrent Versions System - oder: Wie kann man am effektivsten mit einer Gruppe an einem Projekt arbeiten. Denke, dass dieser Bereich zwar nicht unbedingt bei jedem zur Verwendung kommt, allerdings ist das IMO eine ziemlich interessante Sache für alle, die eine ungefähre Ahnung haben wollen, wie in großen Projekten gearbeitet wird.
• Die schönsten Übungsabgaben seit es Dokumentationen gibt: Das LaTeX Listings Paket :p ;)

Biete mich auch gerne - mit nötiger Unterstützung - für die Dinger an...

Zitat:

---

Zitat von MuadDib

• Concurrent Versions System - oder: Wie kann man am effektivsten mit einer Gruppe an einem Projekt arbeiten. Denke, dass dieser Bereich zwar nicht unbedingt bei jedem zur Verwendung kommt, allerdings ist das IMO eine ziemlich interessante Sache für alle, die eine ungefähre Ahnung haben wollen, wie in großen Projekten gearbeitet wird.

---

Uhja! Das wär cool! Wollte ich sowieso schon mal was drüber lernen.. bin aber irgendwie nie näher dazu gekommen. Hier so eine kleine Einführung wär toll. *.*!

CVS ist eine tolle Idee. Vielleicht sollte man auch auf SVN hinweisen.

Ich würde mal Ruby vorschlagen, als äußerst konsequent entworfene und relativ leicht zu erlernende Skriptsprache. Ruby zeigt mir, wie inkonsequent und chaotisch Java ist...
Dann vielleicht noch PCRE (Perl Compatible Regular Expressions). Regexps sind kryptisch, mächtig und unglaublich praktisch.

Als Minifeature könnte man auch mal getopt vorstellen. Damit hat man eine "standardisierte" und relativ bequeme Methode, um Kommandozeilenparameter zu verarbeiten.

CVS is eindeutig klasse. Ich erinner mich noch gut, wie zäh die Programmierung an Minerva ohne CVS war :( (Da fällt mir ein, schon lang keine neuen Sources mehr gezogen)

Und auf die Gefahr hin, dass das nich ganz ins Konzept passt: http://www.digitalmars.com/d/
Is ne Programmiersprache, die als Weiterentwicklung von C++ gedacht ist. Ich hab zwar noch nicht selber damit gearbeitet, weil der Download für die IDE für Windows grad off is, aber das dürfte für manche Programmierer doch recht interessant sein.

Ein Brainfuck Interpreter/Compiler in x86 Assembly, zwar nicht von mir, aber egal.

Code:

---

;; bf.asm: Copyright (C) 1999-2001 by Brian Raiter, under the GNU
;; General Public License (version 2 or later). No warranty.
;;
;; To build:
;;nasm -f bin -o bf bf.asm && chmod +x bf
;; To use:
;;bf < foo.b > foo && chmod +x foo

BITS 32

;; This is the size of the data area supplied to compiled programs.

%define arraysize30000

;; For the compiler, the text segment is also the data segment. The
;; memory image of the compiler is inside the code buffer, and is
;; modified in place to become the memory image of the compiled
;; program. The area of memory that is the data segment for compiled
;; programs is not used by the compiler. The text and data segments of
;; compiled programs are really only different areas in a single
;; segment, from the system's point of view. Both the compiler and
;; compiled programs load the entire file contents into a single
;; memory segment which is both writable and executable.

%defineTEXTORG0x45E9B000
%defineDATAOFFSET0x2000
%defineDATAORG(TEXTORG + DATAOFFSET)

;; Here begins the file image.

orgTEXTORG

;; At the beginning of the text segment is the ELF header and the
;; program header table, the latter consisting of a single entry. The
;; two structures overlap for a space of eight bytes. Nearly all
;; unused fields in the structures are used to hold bits of code.

;; The beginning of the ELF header.

db0x7F, "ELF"; ehdr.e_ident

;; The top(s) of the main compiling loop. The loop jumps back to
;; different positions, depending on how many bytes to copy into the
;; code buffer. After doing that, esi is initialized to point to the
;; epilog code chunk, a copy of edi (the pointer to the end of the
;; code buffer) is saved in ebp, the high bytes of eax are reset to
;; zero (via the exchange with ebx), and then the next character of
;; input is retrieved.

emitputchar:addesi, byte (putchar - decchar) - 4
emitgetchar:lodsd
emit6bytes:movsd
emit2bytes:movsb
emit1byte:movsb
compile:leaesi, [byte ecx + epilog - filesize]
xchgeax, ebx
cmpeax, 0x00030002; ehdr.e_type    (0x0002)
; ehdr.e_machine (0x0003)
movebp, edi; ehdr.e_version
jmpshort getchar

;; The entry point for the compiler (and compiled programs), and the
;; location of the program header table.

dd_start; ehdr.e_entry
ddproghdr - $$; ehdr.e_phoff

;; The last routine of the compiler, called when there is no more
;; input. The epilog code chunk is copied into the code buffer. The
;; text origin is popped off the stack into ecx, and subtracted from
;; edi to determine the size of the compiled program. This value is
;; stored in the program header table, and then is moved into edx.
;; The program then jumps to the putchar routine, which sends the
;; compiled program to stdout before falling through to the epilog
;; routine and exiting.

eof:movsd; ehdr.e_shoff
xchgeax, ecx
popecx
subedi, ecx; ehdr.e_flags
xchgeax, edi
stosd
xchgeax, edx
jmpshort putchar; ehdr.e_ehsize

;; 0x20 == the size of one program header table entry.

dw0x20; ehdr.e_phentsize

;; The beginning of the program header table. 1 == PT_LOAD, indicating
;; that the segment is to be loaded into memory.

proghdr:dd1; ehdr.e_phnum & phdr.p_type
; ehdr.e_shentsize
dd0; ehdr.e_shnum & phdr.p_offset
; ehdr.e_shstrndx

;; (Note that the next four bytes, in addition to containing the first
;; two instructions of the bracket routine, also comprise the memory
;; address of the text origin.)

db0; phdr.p_vaddr

;; The bracket routine emits code for the "[" instruction. This
;; instruction translates to a simple "jmp near", but the target of
;; the jump will not be known until the matching "]" is seen. The
;; routine thus outputs a random target, and pushes the location of
;; the target in the code buffer onto the stack.

bracket:moval, 0xE9
incebp
pushebp; phdr.p_paddr
stosd
jmpshort emit1byte

;; This is where the size of the executable file is stored in the
;; program header table. The compiler updates this value just before
;; it outputs the compiled program. This is the only field in the two
;; headers that differs between the compiler and its compiled
;; programs. (While the compiler is reading input, the first byte of
;; this field is also used as an input buffer.)

filesize:ddcompilersize; phdr.p_filesz

;; The size of the program in memory. This entry creates an area of
;; bytes, arraysize in size, all initialized to zero, starting at
;; DATAORG.

ddDATAOFFSET + arraysize; phdr.p_memsz

;; The code chunk for the "." instruction. eax is set to 4 to invoke
;; the write system call. ebx, the file handle to write to, is set to
;; 1 for stdout. ecx points to the buffer containing the bytes to
;; output, and edx equals the number of bytes to output. (Note that
;; the first byte of the first instruction, which is also the least
;; significant byte of the p_flags field, encodes to 0xB3. Having the
;; 2-bit set marks the memory containing the compiler, and its
;; compiled programs, as writeable.)

putchar:movbl, 1; phdr.p_flags
moval, 4
int0x80; phdr.p_align

;; The epilog code chunk. After restoring the initialized registers,
;; eax and ebx are both zero. eax is incremented to 1, so as to invoke
;; the exit system call. ebx specifies the process's return value.

epilog:popa
inceax
int0x80

;; The code chunks for the ">", "<", "+", and "-" instructions.

incptr:incecx
decptr:dececx
incchar:incbyte [ecx]
decchar:decbyte [ecx]

;; The main loop of the compiler continues here, by obtaining the next
;; character of input. This is also the code chunk for the ","
;; instruction. eax is set to 3 to invoke the read system call. ebx,
;; the file handle to read from, is set to 0 for stdin. ecx points to
;; a buffer to receive the bytes that are read, and edx equals the
;; number of bytes to read.

getchar:moval, 3
xorebx, ebx
int0x80

;; If eax is zero or negative, then there is no more input, and the
;; compiler proceeds to the eof routine.

oreax, eax
jleeof

;; Otherwise, esi is advanced four bytes (from the epilog code chunk
;; to the incptr code chunk), and the character read from the input is
;; stored in al, with the high bytes of eax reset to zero.

lodsd
moveax, [ecx]

;; The compiler compares the input character with ">" and "<". esi is
;; advanced to the next code chunk with each failed test.

cmpal, '>'
jzemit1byte
incesi
cmpal, '<'
jzemit1byte
incesi

;; The next four tests check for the characters "+", ",", "-", and
;; ".", respectively. These four characters are contiguous in ASCII,
;; and so are tested for by doing successive decrements of eax.

subal, '+'
jzemit2bytes
deceax
jzemitgetchar
incesi
incesi
deceax
jzemit2bytes
deceax
jzemitputchar

;; The remaining instructions, "[" and "]", have special routines for
;; emitting the proper code. (Note that the jump back to the main loop
;; is at the edge of the short-jump range. Routines below here
;; therefore use this jump as a relay to return to the main loop;
;; however, in order to use it correctly, the routines must be sure
;; that the zero flag is cleared at the time.)

cmpal, '[' - '.'
jzbracket
cmpal, ']' - '.'
relay:jnzcompile

;; The endbracket routine emits code for the "]" instruction, as well
;; as completing the code for the matching "[". The compiler first
;; emits "cmp dh, [ecx]" and the first two bytes of a "jnz near". The
;; location of the missing target in the code for the "[" instruction
;; is then retrieved from the stack, the correct target value is
;; computed and stored, and then the current instruction's jmp target
;; is computed and emitted.

endbracket:moveax, 0x850F313A
stosd
leaesi, [byte edi - 8]
popeax
subesi, eax
mov[eax], esi
subeax, edi
stosd
jmpshort relay

;; This is the entry point, for both the compiler and its compiled
;; programs. The shared initialization code sets eax and ebx to zero,
;; ecx to the beginning of the array that is the compiled programs's
;; data area, and edx to one. (This also clears the zero flag for the
;; relay jump below.) The registers are then saved on the stack, to be
;; restored at the very end.

_start:
xoreax, eax
xorebx, ebx
movecx, DATAORG
cdq
incedx
pusha

;; At this point, the compiler and its compiled programs diverge.
;; Although every compiled program includes all the code in this file
;; above this point, only the eleven bytes directly above are actually
;; used by both. This point is where the compiler begins storing the
;; generated code, so only the compiler sees the instructions below.
;; This routine first modifies ecx to contain TEXTORG, which is stored
;; on the stack, and then offsets it to point to filesize. edi is set
;; equal to codebuf, and then the compiler enters the main loop.

codebuf:
movch, (TEXTORG >> 8) & 0xFF
pushecx
movcl, filesize - $$
leaedi, [byte ecx + codebuf - filesize]
jmpshort relay


;; Here ends the file image.

compilersizeequ$ - $$

---

(Hab ich bisher nur unter OpenBSD, Gentoo und Debian getestet.)

So, damit haben wir die Kandidaten für den März zusammen; alles unterhalb dieses Posts wird als Kandidat für den April gewertet.

BTW, ihr habt vorher so gezetert, daß ihr auch selbstgeschriebene Sotware drinhaben wollt und dann wird kein einziges Proramm nominiert... Naja, für den Fall, daß es keine Nominierungen gibt habe ich schon einen Notfallplan (siehe Abstimmungsthread).

Ein nettes kleines Prog von mir, das, unauffällig genutzt, einen Datenverarbeitungsleher zumindest verblüffen kann gibt's hier ..

Tyrion LOU

Ich bezweifle, daß irgendjemand dein Programm wählen würde, mit den mageren Informationen. Du sagst nicht mal ansatzweise, was das Programm tut. Nach der Beschreibung, die du da gibt könnte das ein normaler Bildschirmschoner sein oder ein Trojaner, ein Keylogger, eine Spyware-Installationsroutine...
Beschreibe das Programm mal etwas genauer: Was macht es und wie macht es das? Was macht das Programm so besonders?

Und am besten, du gibst den Source auch noch mit. Da das hier ein Programmier-Forum ist, wird das die Leute auch interessieren.

Der Sourcecode is' geheim..

Keine Angst! kein Virus!

Nur ein kleines Prog, das Dezimalzahlen in:
- Binär
- Hexadezimal
- Oktal
- BCD
- Aiken
- Gray
- Römische Zahlen
umwandelt..

Das besondere daran ist, dass das Prog von einem n00b wie mir stammt..

bin grade dabei, eine Erweiterung zu schreiben, die dann jeden der Codes in jeden anderen umwandeln kann..

Tyrion LOU

Zitat:

---

Zitat von Tyrion LOU

Der Sourcecode is' geheim..

---

Und was bitte sollen wir dann von deinem Programm haben ?

ABGELEHNT

Zitat:

---

Zitat von Ineluki

Und was bitte sollen wir dann von deinem Programm haben ?

ABGELEHNT

---

Das wirft eine wichtige Frage auf: Müssen die Programme aus dem Forum PD oder OSS sein? Ich tendiere zu "ja", werde mir aber noch ein paar Meinungen einholen (Sprich: Ich spreche es bei Gelegemheit mal in #progforum an).

Also, ich bin der Meinung, dass hier vorgestellte eigene Programme, die für den Kram des Monats wählbar sind mit Code vorliegen müssen,oder dass zumindest der Code auf Anfrage herausgegeben werden muss. Ansonsten soll der Entwickler sein Prog halt behalten.

Auch wenn ich nicht oft hier bin und kaum proggen kann, ne Idee bring hier doch mal ein. Außerdem können unerfahrene Programmierer wie ich von solchen Codes lernen.

Zitat:

---

Zitat von Jesus_666

Müssen die Programme aus dem Forum PD oder OSS sein?

---

Dafür.
Sonst hat niemand was von dem Programm, außerdem heißt es "Bester Forencode des Monats".

Sehr gutes Argument, mq. Ich mach's dann in den Regeln deutlich.

BTW, ich schlage mal ganz frech was für den Forencode für den Mai^H^H^HApril vor. Dieses Ruby-Skript dient dazu, die Größe einer Reihe von Dateien zu bestimmen; ich verwende es unter OS X als Ersatz für stat. Man kann verschiedene Optionen angeben (wie z.B. die zu verwendende Zahlennorm), die per getopt verarbeitet werden.
Anmerkung: Ja, der Output ist englisch. Mir war gerade so.
Anmerkung, Teil 2: Windows-User sollten sich nicht über die erste Zeile wundern; die erlaubt es *nix-Usern, das Ding direkt als Shellskript zu benutzen.

Der TyNSC II ist in Arbeit.

Neu:
- Umrechnung VON jedem IN jedes Zahlensystem
- Die Möglichkeit, eigene Zahlensysteme zu erstellen
- Version für Windows

Tyrion LOU

Zitat:

---

Zitat von Tyrion LOU

Der TyNSC II ist in Arbeit.

Neu:
- Umrechnung VON jedem IN jedes Zahlensystem
- Die Möglichkeit, eigene Zahlensysteme zu erstellen
- Version für Windows

Tyrion LOU

---

Das interessiert niemand in diesem Thread.
Kannst ja einen eigenen aufmachen - der wird aber sehr wahrscheinlich sowieso geschlossen.

Zitat:

---

Zitat von Tyrion LOU

Der TyNSC II ist in Arbeit.

Neu:
- Umrechnung VON jedem IN jedes Zahlensystem
- Die Möglichkeit, eigene Zahlensysteme zu erstellen
- Version für Windows

Tyrion LOU

---

Was heißt Windows-Version? Benutzt du die WinAPI oder irgendwelchen nicht portabeln Mist? Normale Sourcen in einigermaßen gängigen Sprahcen kann man auch für Linux kompilieren. Oder willst du den Source wieder nicht posten? Dann hat das hier nix verloren.

btw, wenn's kein Tool zur endgültigen Vernichtung ist, würde ich nichts mit "Windows" drin als Feature bezeichnen.

Edit @ Jeez unter mir:
In gewisser Weise trägt wine zur Vernichtung von Windows bei, da man kein Windows mehr braucht, um die Programme laufen zu lassen. Aber du hast recht ;)

Zitat:

---

Zitat von masterquest

btw, wenn's kein Tool zur endgültigen Vernichtung ist, würde ich nichts mit "Windows" drin als Feature bezeichnen.

---

Du solltest dich mal mit den Wine-Entwicklern unterhalten...
BTW, es ist für den Thread gar kein Problem, wenn ein Code die WinAPI benutzt, genausowenig wie wenn das Programm für Cocoa oder Carbon geschrieben ist. Solange die User es nachvollziehen können. (Anmerkung: Wahrscheinlich ist es der Anzahl der hinterher erhaltenen Stimmen aber zuträglich, wenn alle User was mit dem Code anfangen können.)