Re: [Haifux] dual boot with M$-ME and more
On Thu, Mar 21, 2002 at 02:06:07PM +, [EMAIL PROTECTED] wrote: I have just acquired a new laptop(Elonex PIII 700) they installed on in Windoze ME which I'm not familier with for some unknown reason, obviously I am going to Linuxize the computer. does any one have any expirence with dual booting ME? should I excpect problems? as I don't think I've ever done this combo. congrats on your new laptop, meir. winme is a piece of *crap*. you're better off reinstalling from scratch either linux alone or linux dual booting with a reasonable windows (98 if you have to, 2000 if you have it). this assumes that this laptop will be supported out of the box, otherwise you might want to leave the me since it's already configured. secondly, since this is a laptop there is a reasonable possibility I will disscover I require special drivers, what is a good place to start looking? http://www.google.com (but you already knew that) http://linux-laptop.net and last, I don't suppose any one has got a Mandrake 8.2 CD already (hot is it different from 8.1?) not me, sorry. -- The ill-formed Orange Fails to satisfy the eye: http://vipe.technion.ac.il/~mulix/ Segmentation fault. http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Python Lecture
On Mon, Mar 11, 2002 at 07:57:21PM +0200, Orr Dunkelman wrote: Next Monday, 18/3/2, 18:30, Taub 6, mulix will give alecture about Python. first draft[1] of the lecture slides available at http://vipe.technion.ac.il/~mulix/python-lecture/html/index.html [1] this lecture is aimed at beginners. it has two parts - a short (very short) tutorial on python and several scripts and a snippet showing what i do with python. interesting, elegant (and relatively short) code snippets showing the power of python will be most welcome! -- The ill-formed Orange Fails to satisfy the eye: http://vipe.technion.ac.il/~mulix/ Segmentation fault. http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Re: Call For Lectures
On Tue, 12 Feb 2002, Shlomi Fish wrote: On Mon, 11 Feb 2002, Orna Agmon wrote: i have never really programmed using PVM, but it seems like an interesting thing for me to learn. could it be an interesting subject for a lecture? Orna. Isn't PVM a model for parallel-processing and synchronization that can be used on Beowulf clusters? From what I understood, forking or POSIX threads should achieve the same effect. Please tell us more about it. pvm is 'parallel virtual machine'. it can be used on any type of cluster to parallelize applications, and forking or posix threads could not achieve the same effect - unless your cluster supports process migrations (such as compaq ssi, mosix, openmosix, or the yet to be published qlusters os). quoting from the pvm site (http://www.csm.ornl.gov/pvm/) PVM (Parallel Virtual Machine) is a software package that permits a heterogeneous collection of Unix and/or NT computers hooked together by a network to be used as a single large parallel computer. Thus large computational problems can be solved more cost effectively by using the aggregate power and memory of many computers. The software is very portable. The source, which is available free thru netlib, has been compiled on everything from laptops to CRAYs. one of the club's earlier lectures was on 'high performance computing on linux', by shimon panfill (http://linuxclub.il.eu.org/lectures/11/hpcl.ps). perhaphs it should be re-run? -- mulix http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Re: Call For Lectures
On Tue, 12 Feb 2002, Orna Agmon wrote: On Tue, 12 Feb 2002, mulix wrote: i agree. so, who knows pvm enough to talk about it? there's an open slot at 18/03 ;) On Tue, 12 Feb 2002, guy keren wrote: if you build it - they will come. how long until you can give such a lecture? if it'll be realy technical, with live code and running examples, it could be good. mulix, stop trying to post the python lecture- the enemy of the good is the best. point duly noted ;) i can try to be the one after mulix's python. i can try it at work, but i will need help from people with access to computers on the inernet, in order to demonstrate. i guess i could have it run on the same machine (still i will need one machine on the net with pvm , preferably xpvm), but it will not be much of a thing. i can volunteer my laptop and my home server. let me know what you'll need, and i'll try to set it up. pay particular attnetion to firewall rules - pvm is designed to work in an open environment such as a lan, making it work on the internet will probably be an interesting expriment. BTW, and completely unrelated - anyone got old hardware they want to get rid off | barter | sell? i'm looking for all sorts of hackable things, so if you've got anything, please let me know. -- mulix http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] DONT OPEN EMAILS WITH PICTURES !!!!!!!
On Mon, 28 Jan 2002, Orr Dunkelman wrote: Sorry, it'll be regulated in few minutres... ... if you're running microsoft operating systems. sorry, couldn't resist ;) ObLinClub: orr, i'm afraid the date for my python lecture is impossible for me - got a test three days before and a test the day after, or vice versa. please resched. -- mulix http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Linux books - 25% off (fwd)
now THIS is neat. anyone knows the michlol management for next year? gimme cheap linux books, -- mulix http://www.pointer.co.il/~mulix/ http://syscalltrack.sf.net/ -- Forwarded message -- Date: Tue, 13 Nov 2001 09:42:12 +0200 From: David Shadmi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Haifux] Linux books - 25% off Hi list, On the Linux Day (20/11) Dyonon (the campus book store) will sell all Linux books (Hebrew and English) with 25% off (Hod-Ami's books will be 30% off). -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] redhat 7.2 cd needed
hi guys, if anyone coming to the lecture today or in haifa has a redhat 7.2 cd he can burn or spare for a few days, i will be most obliged. it's for a good cause, a windows programmer about to install his first linux and be conveted to the forces of the light. may the holy penguin bless you all, -- mulix http://www.pointer.co.il/~mulix/ http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Re: s/python/syscalltrack/?
On Tue, 23 Oct 2001, Shlomi Fish wrote: I will be happy to hear a lecture about Sys Call Track. Much more than a Python one, in any case, because I can always learn more Python if I made my mind to it. I just don't. glad to hear it. orr, will you please update the lecture list? the lecture will be titled syscalltrack - design and implementation until i think of something catchier. lecturers are guy keren and mulix, and please add a link to http://syscalltrack.sf.net at the extra info column. BTW, Muli, if you'd like to maintain and refactor my make_pysol_freecell_board.py script which is distributed inside Freecell Solver, I will be happy too. Since I'm implementing more and more games, the code became rather ugly. I have some ideas for re-factoring, but I'm too lazy to do so, due to the fact that I prefer hacking on Freecell Solver itself. i'll take a look if you could tell me where to download it from, but i doubt i'll have time to code on it. all of my free time is either syscalltrack bound, or has the expressed purpose of preserving my sanity by doing things Not Computer Related (tm). I can give a lecture about my IP-Noise project, but I'll have to prepare it first. We had to refactor a rather large part of it, before the move to the kernel, and initially we had a full-fledged arbitrator written in Perl. ;-) We found it was useful to have a Perl codebase before the conversion to ANSI C. i'd like to hear such a lecture, whenever you have it ready. -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] If A is A and A is not not-A, does it imply that B is B and B is not not-B ? no signature comment from me ;)) -- mulix http://www.pointer.co.il/~mulix/ http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] s/python/syscalltrack/?
greetings and salutations, the expression in the subject, for the perl challenged amongst you, means 'substitute syscalltrack for python'. i am considering postponing my python lecture on the 17/12 and giving (jointly with guy, if he wants) a lecture on the design and implementation of syscalltrack. the reason is that i do not currently feel i will have enough material to give a satisfactory python lecture (satisfactory means satisfactory to me, not to you). the reason why i will not have enough material is that i'm concentrating all of my free time on syscalltrack. what do you think? would you like to hear about syscalltrack, or will you throw tomatoes at me and demand your python fix? the syscalltrack lecture, should i give it, will be *very* technical, in a format resembling my 'daemons and other monsters' lecture. feel free to reply to the list or to me privately. p.s. more information on syscalltrack can be found at http://syscalltrack.sf.net. p.p.s if we indeed s/python/syscalltrack, the python lecture will be postponed, *not* canceled. -- mulix http://www.pointer.co.il/~mulix/ http://syscalltrack.sf.net/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Updated WMLized linux-day site
On Mon, 8 Oct 2001, Alon Altman wrote: Hi, I've updated Shlomi's WMLized version of linux-day site, and updated the map. Please check out the update site at: http://alon1.dhs.org/ld a few comments: 1. the non frames version looks much better, imho. shouldn't it be the default? or is there an issue with 800x600? 2. in 'configuration' the sentance 'So bring your computer (don't forget problematic hardware if exist)' is a bit awkward - how about 'so bring your computer and any problematic hardware you want to set up under linux'. 3. in 'how to get there', there should be a 'view the map in detail' or somesuch link prominently displayed. 4. in 'Organizers', shouldn't you add 'actcom' to the sponsors list? also, maybe you could add 'haifux' collectively to the organizers list? not related, but does anyone (orr? adir?) know if there will be available network connections and ip addresses for people with laptops, installation machines, etc? last year aduva brought a mini hub (are they coming this year?) and we had a lot of problem connecting to the network. it would be nice if we could set it up in advance this year. -- mulix http://www.advogato.com/person/mulix http://www.sf.net/projects/syscalltrack -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] RFC: Linux Day website
On Sun, 7 Oct 2001, Orr Dunkelman wrote: http://linux-day.il.eu.org or http://linux-day.israel.eu.org some comments. i wont mention stuff mentioned by other people. 1. the gifs at the top and bottom of the page give me a '403: forbidden' error. 2. in about_day.html: intigrated-intergrated. the 'actcom' link opens inside the frame - it would be better if it opened in its own page (or at least on the entire page). 3. in 'configuration', gurues-gurus. 4. in 'how to get there', map_old.gif also gives me '403: forbidden' 5. in 'what to bring', the statement 'linux basicly runs on every pentium or better based PC' is erronous - linux runs on 486, and i think on 386 as well. 6. in 'registration', you can jott me down for anything you want. i shall be around from beginning to end, with maybe short disappearances to classes. i'll be bringing my laptop with 'syscalltrack' running, if anyone wants to see a demonstration or hack on the code together (i can hope, can't i?). -- mulix http://www.advogato.com/person/mulix http://www.sf.net/projects/syscalltrack -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] ANN: syscalltrack version 0.60 released
Haifux, the Haifa Linux Club (http://linuxclub.il.eu.org) is proud to present 'syscalltrack-0.60', the first _alpha_ release of the system-call-tracking linux kernel module and user space utilities. 'syscalltrack' supports both versions 2.2.x and 2.4.x of the linux kernel. * What is syscalltrack? Imagine you have a file being deleted every day at midnight. How will you know which process does it? Imagine you wish to know when any non root process tries to open a file for writing, but you dont care if it tries to open it for reading. How will you do that? Imagine you wish to know when _any_ process tries to temper with /var/log/messages. How will you do it? 'syscalltrack' is a linux kernel module which allows you to hijack and track any system call invocation on your linux box. Using a configuration utility you can specify 'filters' based on both system call parameters and process state parameters. You also specify 'actions' to take if the the filter matches - for example, you can log the invocation to a log file. More actions are planned but not yet implemented. For example, you might say log all processes which try to 'unlink' '/etc/passwd or log all processes which try to 'open' '/dev/dsp' with a mode of O_CREAT, where the UID is less than 100 and the GID is more than 1000. * Where can i get it? Information on 'syscalltrack' is available on the project's homepage: http://syscalltrack.sf.net, and in the project's file release. Files and development information are available from http://www.sf.net/projects/syscalltrack/. You can download the source directly from: http://prdownloads.sourceforge.net/syscalltrack/syscalltrack-0.60.tar.gz * Call for developers: The syscalltrack project is looking for developers, both for kernel space and user space. If you want to join in on the fun, get in touch with us on the 'syscalltrack-hackers' mailing list (http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers). * License and NO Warrany 'syscalltrack' is Free Software, licensed under the GNU General Public License (GPL) version 2. The 'sct_ctrl_lib' library is licensed under the GNU Lesser General Public License (LGPL). 'syscalltrack' is in early _alpha_ stages and comes with NO warranty. If it breaks something, you get to keep all of the pieces. You have been warned (TM). Happy hacking and tracking! -- mulix http://www.advogato.com/person/mulix http://www.sf.net/projects/syscalltrack -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] using unix page: early draft
On Mon, 17 Sep 2001, Tzafrir Cohen wrote: I wanted to write a couple of pages intented mainly for students of the course Matam in the CS faculty in the Technion. This is the course where most of them meet unix. I pu an initial and partial draft in http://www.technion.ac.il/~tzafrir/Haifux/unix_use.html . Comments (possibly in private mail) are welcomed. sent in private mail. In this course the students write two c++ assignments, and one csh assignment (right, Alon?) nope. one c assignment 'advanced c', one c assignment 'modularity (oop) in c', one csh assignemnt and one c++ assignment. -- mulix http://www.advogato.com/person/mulix http://www.sf.net/projects/syscalltrack -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Re: using unix page: early draft
On Mon, 17 Sep 2001, Shlomi Fish wrote: On Mon, 17 Sep 2001, mulix wrote: On Mon, 17 Sep 2001, Nadav Har'El wrote: On Mon, Sep 17, 2001, Tzafrir Cohen wrote about [Haifux] using unix page: early draft: In this course the students write two c++ assignments, and one csh assignment (right, Alon?) Forgive my asking (I guess that everybody here already knows my position on csh ;)), but why is the Technion still teaching csh?? Csh has been considered inferior to almost any alternative (ksh, bash, zsh) for at least a decade... Do they teach csh anywhere else in the world? the technion teaches csh, i suppose, because by the time most students take this course (second semester), the ONLY programming language they've seen is, you guessed it, c. [1] the common wisdom says that it's better not to confuse them with a different programming language syntax. an interesting trivia peace is that the csh assignment is considered by far the easiest in the class, and usually takes the least time to complete. Hello? If C-shell looks like C as much as French looks like English, IMO. Sure, they use the same alphabet, but knowledge on one language will give you very little help in understanding the other. if csh is to c as english is to french, bash to c is as english to arabic. nothing alike, syntax-wise. csh at least LOOKS familiar, which sure seems like a lot to a frightened freshman. I found the bourne shell to have a much better syntax than C-shell, and found C-shell to be awfully limiting and illogical. I think the Technion should make students get used to learning a new syntax, because there are a lot of syntaxes out there. i think the technion should not be teaching c as a first language, but rather c++ or even java. i think (some) technion computer science professors should know what they are talking about even if it is outside their direct area of expertise. i think technion programming excersizes (and tests!) should be more than an excersize in programming trivia. i think a lot of things about the technion's way of teaching, and i've made all of them known to the proper people. did it help? niet. in contrast, i dont mind the technion teaching csh. it's a useful tool. I think that academic studies should teach something that would prove useful outside their academic studies. And C-Shell is not useful. I saw how in an assignment we were given in Structure of OSes (of EE), which csh is useful. there are a lot of csh scripts out there (who knows how many of them were written by technion graduates? ;)) bash is useful too. and so is perl. and sed, and awk. and python, my favorite new langauge. what's my point? i dont have one. i'm just rambling. specifically asked for a C-shell script, two students over-blown their script just so they can handle directory names with whitespace. Needless to say, in the bourne shell this is a non-issue which can be easily solved. there's always a better tool. so what's your point? -- mulix http://www.advogato.com/person/mulix http://www.sf.net/projects/syscalltrack -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] using unix page: early draft
On Mon, 17 Sep 2001, Nadav Har'El wrote: On Mon, Sep 17, 2001, Tzafrir Cohen wrote about [Haifux] using unix page: early draft: In this course the students write two c++ assignments, and one csh assignment (right, Alon?) Forgive my asking (I guess that everybody here already knows my position on csh ;)), but why is the Technion still teaching csh?? Csh has been considered inferior to almost any alternative (ksh, bash, zsh) for at least a decade... Do they teach csh anywhere else in the world? the technion teaches csh, i suppose, because by the time most students take this course (second semester), the ONLY programming language they've seen is, you guessed it, c. [1] the common wisdom says that it's better not to confuse them with a different programming language syntax. an interesting trivia peace is that the csh assignment is considered by far the easiest in the class, and usually takes the least time to complete. [1] ok, they've also seen some pdp11 asm. irrelevant. -- mulix http://www.advogato.com/person/mulix http://www.sf.net/projects/syscalltrack -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] Next Meeting
On Wed, 5 Sep 2001, Orr Dunkelman wrote: Just to remind you that next on Monday, 10/9/01, 18:30, Ez-Aton will speak about Kick start We also will have some discussion about R2L, W2L and the Linux Day. we'll also be talking a little (really, just a little) about syscalltrack - things are looking up and we're getting pretty close to the first public release. guy (or i) will give a short overview of the current status and what needs to be done to make the fabled 0.60 release milestone. speaking of r2l, r2l people - any news? (answers on lin-prj, please). -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] biditext-0.9.4 stupid pigeon released
On Tue, 14 Aug 2001, mulix wrote: http://www.pointer.co.il/~mulix/r2l/biditext-0.9.4.tar.gz * we no longer copy and paste internal code. instead we load xlib dynamically and hook into the functions we need (emil, tzafrir). doh, that's internal *X* code. must stop drinking alcohol before noon. (also, please take replies off lin-club and to lin-prj, when it becomes functional) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] Re: Moshe Zadka will talk about Using and Administrating CVS + key signing.
[linux meeting at biu this friday] anyone going from haifa, please contact me offlist. thanks! -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] the return of the syscall tracker project
hello, clubbers, after a night of fruitful hacking, i'd like to announce the return of the syscall project. for those of you that don't remember, the syscall tracker is a goal started by guy and myself, with the goal of writing a kernel module and a supporting environment that will allow us to: * intercept and take action upon system calls that match a certain user-defined filter * learn about programming for the linux kernel * have fun right now, we have a (semi) functional module working with user mode linux and kernel 2.4 (written by guy for 2.2 and ported by me to 2.4 and uml, which only required a few lines of code but a whole lot of headache), a (semi) specified configuration language and a (semi working) configuaration utility. as you can see, this is most definitely a hackers only release - it's not even close to being useful, and there's a good chance it will crash your kernel - lucky for you it's running in a uml sand box, eh? i opened a sourceforge project, but until it is approved and ready, you can find all of the available code at http://www.pointer.co.il/~mulix/syscalltracker/syscalltracker-0.5.0.tar.gz please let me know if you want to work on this project - there's more than plenty to do. discussion can take place at lin-prj for the time being. happy hacking! -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: r2llib interface change requests
On Sat, 4 Aug 2001, guy keren wrote: On Fri, 3 Aug 2001, mulix wrote: i guess you didnt get my meaning above. if we switch from file existence (r2l state) + size (biditext base dir) to two files (one for r2l state and one for biditext base dir), then we have to have *two* stat()s, anyway. if we need to have two stat()s, i dont like the ugly interface. ok. so lets not use 2 files then. instead, we can encode both attribtues as the size of the file. allocate bit 0 for 'enable' mode. bits 1+2 for 'biditext base state'. thus: size: r2l_mode biditext base direction -- 0 enabled neutral 1 disabled neutral 2 enabled rtl 3 disabled rtl 4 enabled ltr 5 disabled ltr i liked it, therefore i implemented it :) see the release announcement for r2llib-0.21. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: updated r2l-plugins
On Sat, 4 Aug 2001, guy keren wrote: in the gnome applet, note also that whenever you disable biditext (clicking the left button) - the base direction label changes to 'neutral', so when you re-enable biditext, it still remains neutral. this issue will be fixed once the encoding of biditext modes is changed (hopefully soon enough?). done. check the latest r2llib and biditext. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Project Proposal : Simulators for the MAYBE and the G-Machine
On Sun, 5 Aug 2001, Shlomi Fish wrote: On Fri, 3 Aug 2001, mulix wrote: On Sun, 29 Jul 2001, Shlomi Fish wrote: The internals and behaviours of the MAYBE and the G-Machine are described in the book, which is still in print and available in Sifriyath Hadikan. My question is: do you think it will be a valuable project to write these simulators so they would be able to run on Linux, but would also have a back-end that is portable enough to run on any other 32-bit and 64-bit system? This project has the advantage that those who take it will become familiar with the internals of a full-fledged computer, which would be a good experience in digital electronics. i'm not sure how worthy a project it would be, if you consider the following points: * how much hack value does this project have? or to put it another way, how much fun will we have doing it? If you ask me, touching/deleting/polling a file does not exactly have too much hack value either. (not to start a flame war here, but it is a pretty trivial thing to do). This project would give us useful experience in digital electronics and I have some very good idea for a wise design of it. I can elaborate on my ideas if you care. not to start a flame war either, but that is entirely *not* what the project is about. the project is about working together, reviewing each other's code, solving problems (emil's refreshd, encoding both biditext base state and r2l state in one file) and in general writing quality software (compare the new style biditext and old style biditext. they do the same thing, but the glue code is nothing alike...) * will it be usefull to anyone, excepts students taking this class? since i haven't read the book (though i probably will, based on your recommendation), i have no idea what is the scope of the work required, which is another issue to consider. It's bigger than R2L, but if we split it among us, it should not too much time. We can have one session in which we decide on which language to us, which APIs, what the design would be, etc. And then several sessions for coordinating the development. And remember that it involves two separate programs, which we can do at different stages with a break for something else in the middle. i'd hesitate to take on a project whose time to completion cannot be estimated. i think that until we get some more developers (hint, hint, lin-club people) we should stick to small scale projects. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
r2llib-0.21 and biditext-mulix-0.07 crawling earthworms release
hello, clubbers
new r2llib, featuring guy's requested new and improved
void r2llib_query_state(r2llib_t rtl,
R2L_STATE* r2l_state,
BIDITEXT_BASE_STATE* bt_state);
and a new biditext, now using this function and achieving the same speed
as the old style biditext!
* please take a few minutes to look at the diff and spot any
embarassing bugs i may have made. thank you in advance. *
http://www.pointer.co.il/~mulix/r2l/r2llib-0.21.tar.gz
http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.07.tar.gz
r2llib Changelog:
0.21:
biditext_base_state.c: get/set_biditext_base_state() uses
r2l_query/set_state_internal()
r2l_state.c: get/set_r2l_state() uses
r2l_query/set_state_internal()
file_ops.c: new function, create_file_with_size() creates a file
with a certain initial size
query_state.[hc]: new function, r2l_query_state_internal() and
r2l_set_state_internal()
r2llib.[hc]: new function, r2l_query_state()
biditext Changelog:
0.07:
common.c: changed to use new efficient r2l_query_state()
diff -ur r2llib-0.20/Changelog r2llib-0.21/Changelog
--- r2llib-0.20/Changelog Fri Aug 3 23:51:34 2001
+++ r2llib-0.21/Changelog Sun Aug 5 12:04:40 2001
@@ -1,3 +1,13 @@
+0.21:
+ biditext_base_state.c: get/set_biditext_base_state() uses
+ r2l_query/set_state_internal()
+ r2l_state.c: get/set_r2l_state() uses
+ r2l_query/set_state_internal()
+ file_ops.c: new function, create_file_with_size() creates a file
+ with a certain initial size
+ query_state.[hc]: new function, r2l_query_state_internal() and
+ r2l_set_state_internal()
+ r2llib.[hc]: new function, r2l_query_state()
0.20:
changed include guards from _FOO to FOO (emil)
r2llib.[hc]: changed function names to r2l_xxx_xxx(emil)
diff -ur r2llib-0.20/Makefile r2llib-0.21/Makefile
--- r2llib-0.20/MakefileFri Aug 3 23:51:34 2001
+++ r2llib-0.21/MakefileSun Aug 5 12:04:40 2001
@@ -1,5 +1,5 @@
PACKAGE= r2llib
-VERSION= 0.20
+VERSION= 0.21
CC = gcc
DEBUG = -g
PREFIX = /usr/local
@@ -25,8 +25,8 @@
BIN= r2llib-test
LIB_NAME = r2l
LIB= lib$(LIB_NAME).a
-OBJS = r2llib.o r2l_state.o biditext_base_state.o parse_argv.o
r2llib_data.o file_ops.o
-DEPS = r2llib.h r2l_state.h biditext_base_state.h parse_argv.h
r2llib_data.h file_ops.h
+OBJS = r2llib.o r2l_state.o biditext_base_state.o parse_argv.o
+r2llib_data.o file_ops.o query_state.o
+DEPS = r2llib.h r2l_state.h biditext_base_state.h parse_argv.h
+r2llib_data.h file_ops.h query_state.h
EXT_HEADERS= r2llib.h
BIN_OBJS = main.c
CONFIG_BIN = $(PACKAGE)-config
@@ -38,7 +38,8 @@
Doxyfile Makefile $(PACKAGE).spec.in $(PACKAGE).spec $(CONFIG_SRC)\
biditext_base_state.c biditext_base_state.h file_ops.c file_ops.h \
main.c parse_argv.c parse_argv.h r2l_state.c r2l_state.h \
- r2llib.c r2llib.h r2llib_data.c r2llib_data.h
+ r2llib.c r2llib.h r2llib_data.c r2llib_data.h query_state.h \
+ query_state.c
# what about 'rev' ?
TAR_BALL_DIR=$(PACKAGE)-$(VERSION)
TAR_BALL=$(TAR_BALL_DIR).tar.gz
diff -ur r2llib-0.20/biditext_base_state.c r2llib-0.21/biditext_base_state.c
--- r2llib-0.20/biditext_base_state.c Fri Aug 3 23:51:34 2001
+++ r2llib-0.21/biditext_base_state.c Sun Aug 5 12:04:40 2001
@@ -5,63 +5,36 @@
#include r2llib.h
#include biditext_base_state.h
#include file_ops.h
+#include query_state.h
BIDITEXT_BASE_STATE
set_biditext_base_state(const char* file_name,
BIDITEXT_BASE_STATE requested_state)
{
- BIDITEXT_BASE_STATE state;
- int fd;
+ BIDITEXT_BASE_STATE bt = BT_BASE_ERROR;
+ R2L_STATE st = R2L_ERROR;
if (!file_name || (requested_state == BT_BASE_ERROR))
return BT_BASE_ERROR;
- state = get_biditext_base_state(file_name);
- if (state == requested_state)
- return state;
-
- fd = create_file(file_name);
- if (fd == -1)
- return BT_BASE_ERROR;
-
- switch (requested_state){
- case(BT_BASE_RTL):
- if (write(fd, aa, 2) != 2)
- requested_state = BT_BASE_ERROR;
- break;
- case(BT_BASE_LTR):
- if (write(fd, a, 1) != 1)
- requested_state = BT_BASE_ERROR;
- break;
- default:
- assert(0*requested_state);
- /* fallthrough */
- case (BT_BASE_NEUTRAL):
- if (truncate(file_name, 0) != 0)
- requested_state = BT_BASE_ERROR;
- break;
- }
-
- close(fd);
-
+ r2l_query_state_internal(file_name, st, bt);
+ if (bt == requested_state)
+ return requested_state;
+
+ /* we need to set the requested biditext state, while maintaining the
+ r2l state we had
Re: RFC: lin-club-projects mailing-list
On Sun, 5 Aug 2001, Shlomi Fish wrote: [shlomif suggested lin-club and lin-club-programming] [i suggested lin-club-announce and lin-club] I don't think the projects are the core reason for the club's being. The way I see it, the club exists because people happen to like Linux and the various software associated with it, and enjoy giving and attending lectures about it, and (but not only) enjoy conducting projects that relate to it. Do you imply that if the club did not produce a single line of source code, it would have had no right to exist? of course it would have a right to exist. but to be called a 'linux' club, without producing code - that's open to debate. you might recall me making an informal survey, and finding out most (all?) of the club's members are programmers. i think, i really do, that a club full of prgrammers should be, at least in part, about programming... Back to our subject: the reason I suggested the split is to increase the signal-to-noise ratio of the mailing-list for those who are not interested in disucssing the minute details of the projects we take. I do not imply by this, that the projects are any less part of the club's activity. could we have a show of hands, please? how many of you, club members, read or skip r2l related mails? -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Project Proposal : Simulators for the MAYBE and the G-Machine
On Sun, 5 Aug 2001, Shlomi Fish wrote: On Sun, 5 Aug 2001, mulix wrote: i'd hesitate to take on a project whose time to completion cannot be estimated. i think that until we get some more developers (hint, hint, lin-club people) we should stick to small scale projects. Part of the reason I cannot estimate its time to completion is because I don't know how many developers are going to work on it. However, I'm not sure if more developers will make the situation better because the project can be parallelized only to a certain extent. Some parts of the code needs to be written by one group synchronously. actually, more developers can sometime hinder a project, as the prophet brooks reminds us. (not, not mel brooks, frederick p. brooks, jr, author of the mythical man month) But I can tell you in advance that the MAYBE simulator will not take too much work. And I believe we can split it into several steps, that each one would be a mini-project of its own. That way, we can take some time to procastinate with different projects. Would you agree to delay the final verdict until I rent the book and write a more detailed description of the MAYBE's internals, as well as a specification of the simulator's code, as I can plan it in advance? we can always schedule it, if there's sufficient interest, after guy's attach and detach programs. personally, i'd like to hear this description anyway (i'd like to read the book too... if only there were 48 hours in a standard earth day). -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Detaching and Attaching a Process [was Re: Project Proposal ]
On Sun, 5 Aug 2001, Shlomi Fish wrote: Yes, but the question is if it is possible that a process will redirect the stdin/stdout/stderr of another process after the process is running? Guy, is there a predefined API for this, or will it require some kernel hacking? If such an API exists, is it Linux specific, or is something standard? no predefined api. no kernel hacking necessary (i think). but it will most definitely be a hack. and a cool one, too ;) for more information, read the following linux-il thread: http://plasma-gate.weizmann.ac.il/Linux/maillists/01/06/msg00217.html -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
r2llib-0.20 and biditext-mulix-0.06 soaring eagles release
hello, clubbers, a new r2llib is amongst us, based on emil's code review. it has these major changes: * r2llib.h has changed, to make the interface more consistent. all users of r2llib, you *will* need to patch your code to work with this version of r2llib. thankfully, it's a simple matter of search and replace, as only the function names changed, the semantics did not. * BT_ERROR is now BT_BASE_ERROR, for consistency. also, a new version of biditext, to use the above mentioned new interface and fixing a bug which (should) have prevented it from running at all... did anyone actually try biditext-mulix-0.05? http://www.pointer.co.il/~mulix/r2l/r2llib-0.20.tar.gz http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.06.tar.gz TODO: * decide on a better encoding for the biditext base state property (a different file?) * optimize the biditext critical path in r2llib. r2llib Changelog: 0.20: changed include guards from _FOO to FOO (emil) r2llib.[hc]: changed function names to r2l_xxx_xxx(emil) r2llib.h: added #ifdef _cplusplus (emil) biditext_base_state.c: bomb on default in set_biditext_base_state instead of ignoring it (emil) file_ops.c: remove redundant if() from create_file()(emil) main.c: changed r2l function calls to new interface (mulix) parse_argv.c: --file-name is now --r2l-file-name in parse_command_line (mulix) r2l_state.c: added default clause to switch in toggle_r2l_state() (emil) r2llib.c: added assert() to all functions (emil) r2llib.c: changed memcpy/strcat to snprintf() in r2l_init() (emil) r2llib_data.c: bomb if file_name is null in create_r2l_data() (emil) r2llib_data.c: check for null rtl in destroy_r2l_data() (emil) Makefile: added -O2 to CFLAGS (mulix) r2llib.h: changed BT_ERROR to BT_BASE_ERROR (guy) biditext Changelog: 0.06: Makefile: remove redundant R2LLIB_CONFIG_DIR (mulix) common.c: use r2llib-0.20 api (mulix) common.c: fixed embarrasing *prtl = rtl bug (mulix) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: r2llib interface change requests
On Fri, 3 Aug 2001, guy keren wrote:
On Fri, 3 Aug 2001, mulix wrote:
2. there should be a single function that gets both r2l mode and biditext
base directionality - using a single stat() call. having to call 2
seperate functions is inefficient - especially inside biditext's string
drawing code...
this becomes largely irrelevant if we switch from file + size to two
different files...
in that case, i doubt the interface ugliness will be worth it for the
little gain of saving one function call.
no, no. this function is in the critical path (teh one used by the
biditext library, on each string drawing). now think of a desktop with
several applications, several windows for each, all trying to perform a
screen redraw
i guess you didnt get my meaning above.
if we switch from file existence (r2l state) + size (biditext base dir)
to two files (one for r2l state and one for biditext base dir), then we
have to have *two* stat()s, anyway.
if we need to have two stat()s, i dont like the ugly interface.
and its not a function call - its a system call. much more costly...
and the interface isn't realy ugly. it just gets an r2l instance, and 2
poitners - one for an R2L_STATE variable, and one for a
BIDITEXT_BASE_STATE variable. something like:
int r2l_query_state(r2llib_t rtl,
R2L_STATE* r2l_state,
BIDITEXT_BASE_STATE* bt_state);
this is not so ugly, and more efficient for the critical path...
it is ugly, since it forces me to do one of the following:
* implement it in terms of already existing functions - we win exactly
one function invocation in that case.
int r2l_query_state(r2llib_t rtl,
R2L_STATE* r2l_state,
BIDITEXT_BASE_STATE* bt_state)
{
assert(rtl r2l_state bt_state);
*r2l_state = r2l_get_current_r2l_state(rtl);
*bt_state = r2l_get_current_biditext_base_dir(rtl);
}
* implement it by cutting and pasting (hideous) or reorganizing the
existing code to use this function, forcing a much tighter coupling of
the r2l state and biditext base state.
int r2l_query_state(r2llib_t rtl,
R2L_STATE* r2l_state,
BIDITEXT_BASE_STATE* bt_state)
{
assert(rtl)
if (r2l_state)
*r2l_state = knowledge specific to r2l_state
if (bt_state)
*bt_state = knowledge specific to bt_state
}
R2L_STATE
r2l_get_current_r2l_state(r2llib_t rtl)
{
assert(rtl);
R2L_STATE res;
r2l_query_state(rtl, res, NULL);
return res;
}
we win nothing in either case. the only reason to have such an interface
is if it gives us *real wins* over the seperate function for each state.
for the two files case, i dont see how it can do that.
--
mulix
http://www.advogato.com/person/mulix
linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
r2llib-0.08 and biditext-0.04 sniffing baboons release
another night, another release. and it's not even dawn yet. http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.04.tar.gz http://www.pointer.co.il/~mulix/r2l/r2llib-0.08.tar.gz * please help test biditext. get it, compile it, install it, run it. * * thanks to tzafrir for the rpm and doxygen stuff in r2llib * * any X gurus know if XDrawString has a limit on the size of the string it accepts for drawing? * r2llib Changelog: 0.08: added doxygen support and rpm support (tzafrir) added packaging support to Makefile (tzafrir) biditext-mulix Changelog: 0.04: do_biditext8() and do_biditext16() now return the buffer on success and NULL on failure added internal 4096 chars limit test to do_biditext8() and do_biditext16() moved do_biditext8() and do_biditext16() into common.c commo8.c, common16.c - removed ripped out the biditext initialization code from init_biditext(), now it uses r2llib_init() only Makefile - made r2llib location relative to biditext dir -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: I cannot give the GIMP lecture the Monday after next
On Thu, 19 Jul 2001, Shlomi Fish wrote: I tell you in advance that we should probably delay the R2L discussion by a week and have my lecture the Monday a week from then. I don't want to be pressured enough to give the GIMP lecture. And my cousin invited me to go with him to Eilat (Muli isn't the only one that has vacations) ok, here's the current (template) schedule: 6/8/2001 - r2l discussion 13/8/2001 - adsl (me) or gimp ii (shlomi) 27/8/2001 - ssl (orrd) 10/9/2001 - gimp ii (shlomi) or adsl (me) or python (me) 24/9/2001 - python? emacs? vi? something else? shlomi, what schedule do you prefer? (personally, i would prefer to delay the python lecture until october or so) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Report on 1st Gimp Lecture + The 2nd Gimp Lecture
On Tue, 17 Jul 2001, Shlomi Fish wrote: lectures. Orr, could we swap the GIMP lecture with another one, or do I have to give it somewhere after the Python lecture (Sep 10) which is 10 weeks from now? From a quick glance it strikes me that Muli can postpone his ADSL lecture (or the Python one) to September 24 (or to after the summer vacation?) allowing me to give the GIMP at August 13. Muli, is it OK with you? postponing the python lecture to the 24th is fine with me. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Suggestion for a lecture: GNU/X Emacs
On Tue, 17 Jul 2001, Shlomi Fish wrote: By anyone I refer to Muli, but it's possible that others are expert enough to give it. I, on my part, have lost hope of getting used to it on my own. i am not, by any stretch of the imagination, an emacs expert, but if no one else wants to, i'll happily give the lecture. however, i have a suggestion: how about an emacs - vi shootout? we could have an emacs person and a vi person, each will explain why they use that particular editor, and why their editor is the best, and then proceed to answer the audience's questions and demonstrate how to do 'foo', for different values of 'foo'. then the other person will demonstrate how to do 'foo' in the other editor. what do you say? that way we get 2 good editors for the price of 1... any vi users? choo, wanna prove once and for all vi is best and show off you neat hanoi towers in vi macros? :) btw, we can make it an n way shootout, if anyone uses another editor and would like to discuss it. (pico users need not apply) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
request to postpone the r2l project discussion on 30/7
i just saw the date and a huge brick dropped on my head - i wont be here then, i'm going to be making a spectacle of myself in club med at that date. what do you guys say we postpone it in one week, so i could attend too? i'll be bringing the promised pizzas then, so there's an incentive :) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Suggestion for a lecture: GNU/X Emacs
On Tue, 17 Jul 2001, Nadav Har'El wrote: What if I think that both vi and XEmacs are the best? Is there room for a double-agent in such a panel? :) of course there is. only one dimensional people see the world in black and white. i personally use both vi and emacs frequently, but for completely different purposes. nadav, you know you're always welcome to the panel. What about Sam (plan 9's editor, I think)? ed? ;) if you volunteer to talk about it, i volunteer to listen. Next shootout: which shell is better! bah, real man toggle memory bits with front panel switches. shells, and keyboards, are for weenies! -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Suggestion for a lecture: GNU/X Emacs
On Tue, 17 Jul 2001, Stas Cherkassky wrote: I more then support the request. I personally voted by feet for vim after I couldn't find in Emacs a feature equivalent to word completion feature of vim (I mean Ctrl-n or Ctrl-p). This could be my first question for an Emacs guru.. go no further: M-. (that is the meta key, followed by the dot key) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Suggestion for a lecture: GNU/X Emacs
On Tue, 17 Jul 2001, mulix wrote: On Tue, 17 Jul 2001, Stas Cherkassky wrote: I more then support the request. I personally voted by feet for vim after I couldn't find in Emacs a feature equivalent to word completion feature of vim (I mean Ctrl-n or Ctrl-p). This could be my first question for an Emacs guru.. go no further: M-. (that is the meta key, followed by the dot key) doh! i shouldn't be doing email before drinking my first cup of coffee. word completion is M-/ , not M-. they were next to each other on the keyboard and i didnt look which key i was actually pressing before emailing ;) (btw, M-. is 'visit tags table'. wanna know what that means? good, because i want to know too) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: I have a few quiestions to ask...
yup, and unless i'm mistaken, eli gave a lecture on it. yup - http://linuxclub.il.eu.org/lectures/26 On Wed, 18 Jul 2001, Shahar Dag wrote: Hi Can one create his own Linux boot CD to match his computer needs? Shahar -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
r2llib-0.07 and biditext-0.03 cavorting pandas release
hello, pizza hungry clubbers, another night, another release. get it from the usual place, http://www.pointer.co.il/~mulix/r2l/r2llib-mulix-0.07.tar.gz http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.03.tar.gz emil, your pizza is secured and the bug is fixed. thanks for spotting it! biditext-0.03: 0.03: Text16.c - made string_final a static buffer common.c - added a NULL check before dereference r2llib-0.07: fixed stupid bug in r2llib_data.c [reorder malloc, null test and memset] (emil) biditext_base_state.h - documentation biditext_base_state.c - cleanup file_ops.c - cleanup parse_command_line.c - fixed stupid bug fix bug [ptr *ptr good, ptr || *ptr bad] r2llib.c - cleanup r2llib.h - cleanup -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
r2llib-0.06 and biditext-0.02 twirling cockroaches release
hello, clubbers. biditext-mulix-0.02 works. get it, use it, play with it, let me know if anything bad happens. unless it's too bad, in which case, i dont want to know. http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.02.tar.gz http://www.pointer.co.il/~mulix/r2l/r2llib-mulix-0.06.tar.gz r2llib Changelog: 0.06: fixed stupid bug [pointer dereference without NULL check] in parse_command_line() (mulix) biditext-mulix Changelog: 0.02: do_biditext8() and do_biditext16() return true/false. the reversed string is returned by reference. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: refreshd-0.0.1
On Sun, 15 Jul 2001, Kohn Emil Dan wrote: Main features: * support for multiple displays * support for multiple .rev control files * requires r2llib-0.0.4 (as I can see I'm a little bit out of date) but it takes the filename from r2llib and uses stat() to check for file changes (i.e. it peeks under the r2llib's skirt. Shame on him!!! :-) Things to do: * better integration with r2llib i'll look into this tomorrow. * DOCUMENT IT!! this one you'll have to do :) Do you have site where I can upload it? i'll be happy to put it on my site, if you'd like. otherwise, the club's site, probably. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
biditext hacking galore
hello, clubbers! are you a shared library guru? are you courageous, advanterous, bold and cunning? do you eat linkers for breakfast, and compilers for lunch? is your name linux torvalds? would you like to make history, and make me eternally gratefull? if you answered 'yes' to any of the above, biditext-mulix-0.01 is ready for you. this is a hackers only release, for the simple reason that *it does not work yet*. if you want to help me fix it, get it. if you want to see the code, get it. if you want to actually use it, dont bother getting it.. biditext-mulix-0.01 is based on biditext-0.9.1, with two major differences: 1. the code is cleaned up. no more code snippets in various files getting included by various other files. 2. it uses the r2llib library for communications. get it from http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.01.tar.gz to compile, you need to also fetch r2llib-mulix-0.04. unpack and compile r2llib, and change the biditext Makefile to point to the directory where you unpacked r2llib. what happens now is that when you run a program with this version of biditext it will start and immediately die. i havent tracked down the bug yet, but i will. unless *you* beat me to it. TODO: * optimize ruthlessly * profile against the original biditext. * optimize r2llib as used in biditext -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: My Perl R2L Program vs. r2llib
On Wed, 11 Jul 2001, Shlomi Fish wrote: I'm not very reluctant to use Muli's r2llib because that way the portability of my perl program will be harmed. I don't mind the C implementations use it, but it seems that maintaing a perl implementation vis-by-vis with the C one, will be a better idea in the long run. i agree with you, *provided* the perl implementation behaves exactly the same way as the c implementation. otherwise, we might confuse the users. What I need to know, is how exactly does r2llib responds. Is it enough for the file to exist? Should it be readable? Can it be a directory? Etc. check out the code. you want r2llib.c, r2l_state.c, biditext_base_state.c and file_ops.c. it should be very easy to follow, if it isnt, let me know (or send me patches ;)) And what is this file-size stuff? see the archives for the full story. tzafrir brought up another property we might wish to communicate to biditext, the base r2l direction. this property is communicated via the file size. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
r2llib-mulix-0.04.tar.gz (testing, testing, 1, 2, 3)
looks like this is the last version. hooray. get it at the usual place: http://www.pointer.co.il/~mulix/r2l/r2llib-mulix-0.04.tar.gz Changelog: 0.04: added simple tests for all functionality (mulix) changed the opening flags in file_ops.c:create_file() to give the user write permission (mulix) 0.03: changed biditext_base encoding to use file sizes, per tzafrir's suggestion (mulix) 0.02: various compilation fixes(tzafrir, mulix) small main() (mulix) 0.01: initial version(mulix) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: 'r2l' continuation
On Sun, 8 Jul 2001, guy keren wrote: at first i thought of using mmap, but if we use mmap, as guy has mentioned, we cannot know that when a file has been erased. so i took things to the next logical conclusion, shared memory. what? shared memry now? you have any idea how problematic usage of shared memory is? also, you cannot delete a shared memory page if any process has it attached, so you cannot rely on its existance - only on its contents. right. so what? you'll also have problems if you want many copies of biditext in memory, each usign a different shared memory segment - OSes limit the number of shared memory segments that can exist (OS-wise) at any given time. i need two bytes of shared memory, and one is enough if i care to use bits instead of bytes. i will check what's the limit on linux, but i doubt it will be relevant. its hard to clean up shared memeory segments, since you have to explicitly erase them. so? comments? i'm in favor of trying the shm approach, falling back to files if it doesnt work out. if you wish to make a private version of the library with shared memoery - do so. i will. but first - release a version that does the simple thing we asked for - using files, and using tzafrir's hack (file size) to check for bidi mode. please, guy, the simple version you want is released and has been released since 05:22 on july 4th. it has the 'base biditext' support, and although it currently uses open/read/write, the interface is set and will remain the same no matter what method we choose. then we could start working on ther others parts (putting the lib into biditext, and into r2l programs) and you can meanwhile play with it. i will put out right now a new version with the file size hack. i will put out a shm version when i write it. please, lets be focused on having something working in 3.6 weeks from now.. please specify the next steps... -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
r2llib-0.03 (file sizes hack) is available
http://www.pointer.co.il/~mulix/r2l/r2llib-mulix-0.03.tar.gz get it while its hot! -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: 'r2l' continuation
On Fri, 6 Jul 2001, guy keren wrote: On Wed, 4 Jul 2001, mulix wrote: i decided that as long as we use files, we might as well make full use of them. therefore, i store in the file the 'biditext bidi' property in plain text, as the tokens 'neutral', 'rtl' and 'ltr'. oh! but thus you have defeated tzafrir's original purpose of using the file size - so the data can be taken with a single fstat() call, rather by using fstat(), open(), read() and close(). remmeber this code will be invoked on each XDrawString* function call inside biditext.so ... is this absolutely necessary? if we add polling, in whatever sort, the value can be cached until we get a notification that it has changed. if we assume no polling, however... i suggest you switch back to reading file sizes. i dont like this way. it's a hack. let's see if we can find a better hack :) at first i thought of using mmap, but if we use mmap, as guy has mentioned, we cannot know that when a file has been erased. so i took things to the next logical conclusion, shared memory. consider this scenario: a biditext enabled application starts up and tries to attach to a shm segment. if the shm segment is non existent, biditext is disabled. if the shm is existent, we can read from it the 'base biditext' proeprty and whether biditext is enabled or disabled. an r2l application will create the shm segment (or not) on startup, and write to it the relevant values. obvious advantage: * very fast (shm is the fastest IPC mechanism) obvious disadvantages: * cannot be easily controlled from the command line (no rm, touch equivalnet) * harder to code. * default is biditext disabled, unless we make sure to create the shm segmnet with the right values before any biditext apps come up. comments? i'm in favor of trying the shm approach, falling back to files if it doesnt work out. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: 'r2l' continuation
On Tue, 3 Jul 2001, guy keren wrote:
i think that a good method to keep going forwards is as follows:
we have our arguments. we'll have several competing implementations done.
some (group A) will keep working (i.e. actually coding) with the current
file-based mechanisms, and try to enhance it to work on a per-window
situation, and make it work with as many applications as possible. noet
that this approach will be good enough for the home user, who runs all
their apps on a single machine, and thus for them, 1 display = 1 file
system.
i'm in.
let the trials begin!
very well. i now refer to your original email, which started this
thread.
1. combine the r2l efforts.
in what way? for what purpose? let's define *exactly* what our r2l needs
to do, so we know what to code ;)
2. take out the 'file manipulating' part into a seperate library,
that will be used by all programs (biditext, r2l and any relevant
daemon process, if any).
i can do this easily. check out file_ops.[hc] in my r2l package.
here's my interface, anything else we need?
/* gets one char* parameter, the name of the file to check */
/* returns 1 if it exists, 0 if not, -1 on errors */
int file_exists(const char* file_name);
/* return 1 if the file was deleted, -1 on errors */
int delete_file(const char* file_name);
/* return the file descriptor ( value = 0 ) on success and -1 on errors */
int create_file(const char* file_name);
3. modify biditext itself to contain the auto-refresh enhancements,
instead of keeping two seperate libraries.
emil, can we see your top secret code? doesnt matter if it still has
bugs, we know bugs and bugs know us.
4. decide how the GUI should look and behave, and make it the same
on all desktop environments.
i'll leave this one to the gui experts... just make sure it's small,
simple and consistent.
i think the file manipulating library (or rather, biditext communications
library, since in the future we might replace the usage of files with
another mechanism)
this library is to be used for biditet and the various r2l apps to talk
to each other, right? so it should support the following (minimal)
interface:
typedef enum{
R2L_ENABLED,
R2L_DISABLED,
R2L_ERROR
} R2L_STATE;
typedef r2llib_type* r2llib_t;
/* initialize */
r2llib_t r2l_init(int* argc, char* argv[]);
/* perform cleanup */
void r2l_destroy(r2llib_t r2l_data);
/* return 1 on success, -1 on failure */
int enable_r2l(r2llib_t r2l_data);
/* return 1 on success, -1 on failure */
int disable_r2l(r2llib_t r2l_data);
/* return 1 on success, -1 on failure */
int toggle_r2l(r2llib_t r2l_data);
/* return the current r2l state on success, R2L_ERROR on failure */
R2L_STATE get_current_state(r2llib_t r2l_data);
anything else? this can be a simple interface, where the actual
operations are mapped one to one to the file operations outlined
earlier.
--
mulix
http://www.advogato.com/person/mulix
linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: 'r2l' continuation
hi tzafrir, is this a property the 'l2r' programs should be able to read/modify? is this something that most users will want/need to modify? how do you suggest we give a graphical interface to it? (an obscure interface is almost as bad as no interface at all) isn't leaving the default as 'neutral' good enough for most (all) of the cases? (i have no problem with extending the possible states or adding a new set of states, i'm just not sure it's necessary). On Tue, 3 Jul 2001, Tzafrir Cohen wrote: As I've said before, I believe that biditext should have a couple of more sstates. Spesifically, the base bidi direction. Perhaps it should be a seperate type, and not part of R2L_STATE. Possible values: Neutral: should be the default (I believe) LTR: Right-to-Left (is currently the default) RTL: Left-to-Right Explanation: the bidi algorithm (the function that converts from logical to visual) leavs one decision to the caller, because it depends on the context: what is the direction of the environment in which this text resides. For instance, in Windows' text entry widget (and in notepad, that uses this widget) you can choose between either LTR and RTL by pressing Ctrl-Left_shift or Ctrl-right_shift (accordingly). If the base direction is neutral, then the string's direction will be determained by the first strong-directionality character, which is a relatively good heuristic (but fails if a line of hebrew text happens to begin with an english word or a number. (Nadav or anybody: would you mind giving a clearer explanation?) Currently biditext calls fribidi_log2vis with a base direction of LTR . This means that if a hebrew sentence containing a latin character it will be rendered incorrectly. If any of you remebers/uses btkbidi: it has a neutral direction by default, but the direction can be set by the user explicitly to RTL or LTR. I did a simple implementation of such a change. I didn't want to make any other system call, so I decided that for a quick-and-dirty implementation I better abusse the st_size field of the stat() result (Muli: to answer your question: the code checks: if stat()!= -1). if size is 0: direction is neutral (touch .rev, echo -n ~/.rev) if size is otherwise even: direction is RTL (echo a ~/.rev) if size is odd: direction is LTR (echo ~/.rev) The required changes were fairly trivial. But anyway, I have put: http://www.technion.ac.il/~tzafrir/biditext-0.9.1-size-dir.tar.gz http://www.technion.ac.il/~tzafrir/biditext-0.9.1.tar.gz (I also updated 0.9.1 today. It now really includes an rpm spec file, but it doesn't include the original r2l. No need to boter...) I'm not sure that this feature is required, but I believe that it needs testing. Even if it does stay, the abuse of the file size property should go away ASAP. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: My own R2L Program
On Tue, 26 Jun 2001, Shlomi Fish wrote: I hate to discourage you, but I believe the file creation/deletion/polling logic is actually the easy part of this project. I found creating a fully it is only easy if you make it easy, by which i mean that it's easy to do, but hard to do _right_, at least in a language such as c, imho. (the polling and notificaton part, that is. file deletion and creation is easy) usable and functional GUI for it, much harder. Maybe it's that my GUI skills got a little rusty, but right now I spent much more time on the GUI and have more LOCs in it. glory be to you, then. personally, i find gui programming a bore, so i do as little of it as possible. My R2L program uses a couple of perl modules as its creation/deletion/polling backend. I see no reason to use your r2llib instead, because C code is harder to debug inside a perl program and is generally more error-prone and touchy. you want reasons? abstraction modularity quality of code fitness to the task being performed a stable api that's just off the top of my head, and i will eleaborate further at the meeting. the library is especially suited for c c++ programs, but it could be given language bindings to other languages, it's interface is quite simple. I believe coding the GUI was the entire point of this assignment. So let's roll those vertical boxes... ;-) i completely disagree - the purpose of the assignment is to code something that vaguely has to do with 'r2l', and present it to the other club members. you chose to write a gui, good for you. i wrote a library, a gnome panel applet which uses this library and (will write) a python script, maybe with pygtk. i look forward to seeing what the other guys have done! -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: next year - instaparty and welcome to linux
i volunteer to give whatever lecture is necessary. specifically, i would like to give a lecture called 'programming [for|with] linux'. On Fri, 22 Jun 2001, Shlomi Fish wrote: On Thu, 21 Jun 2001, Orr Dunkelman wrote: Well, I agree. We need to start thinking this over. OK. We should prepare the sequence of the lectures and who is going to give them. I volunteer to give the Shell lecture. As opposed to three -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: r2l, gnome applets and window managers?
On Wed, 20 Jun 2001, guy keren wrote: second - i was wondering about support for an application to dock into other types of toolbars. tzafrir - you mentioned support for window maker. i assume you refer to desktops running window maker without gnome and gnome's panel? where'd i go about starting to see how to write a window maker dockable application? do i write it using gtk, or i have to use some other toolkit? please share this info. thanks. even though i probably wont add support for other desktops or window managers other then gnome, it will still be nice to have pointers to the relevant FM. in any event, i'll reveal the code during the r2l meeting we're having at Haifux on the 2-july. did other people also get started with working on r2l? i did, as you know. anyone else? -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: r2l, gnome applets and window managers?
On Wed, 20 Jun 2001, Tzafrir Cohen wrote: [guy wrote] second - i was wondering about support for an application to dock into other types of toolbars. tzafrir - you mentioned support for window maker. i assume you refer to desktops running window maker without gnome and gnome's panel? where'd i go about starting to see how to write a window maker dockable application? do i write it using gtk, or i have to use some other toolkit? Hmmm... It seems that it is mostly me interested in this, so I better do something about this. perhaphs i should mention that both guy and i have implemented a 'pluggable' architecture, where the 'r2l' code is completely seperate from the gui code. guy did this using plugins, and i wrote r2l as a library you can link with. we could share efforts... after all, this is not a competition to see who has the biggest^W best code. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
ADSL lecture
hello, lin-clubbers, based on the responses received so far, i'll be happy to give an ADSL lecture. subjects will include: a. how adsl technology works (brief overview) b. how adsl conections work, both in general and the linux implementatio. c. some adsl war stories and anecdotes, if we have the time. orr (guy?) please schedule the lecture for anytime after july 24th (my last exam). -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
IP Over Avian Carrier (RFC 1149)
sorry for posting stuff from /., but this is too cool for words. i feel our linux club ought to do something intersting like this too. suggestions? http://slashdot.org/articles/01/04/30/0555218.shtml -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
linux (paid) help wanted
hello, club. one of my math professors approached me today, and asked if i knew anyone who could help her fix her dial up connection under linux. she is willing to pay for the work. she could not explain to me what the problem was exactly, except that sometimes she couldn't send files to the technion and it works in windows. so, if anyone is interested in going over to her house and finding out what's the problem and solving it (she lives in ahuza), for a fee, please contact me. you must be able to solve such problems, naturally, and preferably be familiar with the technion's network. (p.s. she's really nice, as far as math professors go) -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Recommendation on Linux Books
On Sun, 22 Apr 2001, Shadi (shoosh) wrote: 2) Maximum Linux Security (The writer is mentioned as "Anonymous" :) Publisher: SAMS - www.samspublishing this one is (was?) available for free over the net. didn't strike me as a particularly good book, buy YMMV. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: again, in need of a linux cd
well, thanks very much to all who responded. i now have an installation cd and installing linux on the laptop as i write this. thanks again! mulix wrote: well, it appears that once again i find myself in dire need of an installation cd, and approach this august body for said cd. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
Re: Announcment on a Lecture
Hi everyone, the lecture slides and the accompanying code are available for the time being on http://www.pointer.co.il/~mulix/. orr, let me know when vipe recuperates and i'll send you the code and the slides for the lecture in a tar.gz. Orr Dunkelman wrote: On 22/1, next Monday, at 18:30, Mulix is going to talk about System Deamons (or How to kill your deamons - without using holy water). The usual meeting place (Taub 6, CS Dept. bldg.) -- mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
