From stdrange at uchicago.edu Mon Nov 18 03:08:25 2002 From: stdrange at uchicago.edu (Stephen Dranger) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Update on E17 project Message-ID: <3DD8AE09.40808@uchicago.edu> Here's a list of tasks accomplished, and our Goals for the project. Done so far: - Downloaded the super-secret SPLIT branch of the cvs tree. - Compiled libs, apps on multiple machines - Currently, we have a set of library functions that will take a snapshot of the current X root by querying the X window tree. This will return a dynamic, null-terminated array of window property structs. These functions will eventually be integrated into our ecore library additions. For now, it's just a single library file that our rudimentary "Zibar" uses to display a list of window clients, and differentiate between iconified and normal windows. Zibar uses existing e library function calls, most noticably, evas, the E canvas, and of course ecore. No extraneous X calls are made by the Zibar. Goals: 1: Develop proper client listening functions. This includes: a) Registering for and listening to X Windows calls. b) Responding correctly to these calls c) Setting up self as client list that Taskbar-hopeful apps can listen to. 2. Develop API for taskbar core functions. Figure out what would make things easier for users. 3. Clean up, integrate into Ecore. Nervously submit to Raster. From wes at uchicago.edu Mon Nov 18 03:45:15 2002 From: wes at uchicago.edu (Wesley Pegden) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] gcc update Message-ID: <3DD8B6AB.5070106@uchicago.edu> GNU GCC A project update. Building on my original plan to generally help clean up GNU's GCC code, I set out to write some scripts to help me do that work for them, and to help others do the same in the future. IF0*STUFF********************************* GCC's project page complained that their code was speckled with preprocessor #if 0 statements--often sitting around in the code version after version doing nothing but getting in the way. The script I wrote (in C) as a helper for this problem is reasonbly simple. In its original form, it looks something like this... __________________________________ open a source file (i.e file.c) while there is a next line of the file, look at the next line. Cut off the inital whitespace characters. If the result is #if 0, copy the line number and line text to the next line of file.c.if0s, and continue to copy text to file.c.if0s until one has exited the #if0 statement Repeat ___________________________________ In my code, I used a separate function to remove the initial whitespace characters for clarity and convenience. While functional, I increased the utility of the script by letting it accept a list of files to go through and act on as above. Now my structure is something like this.... Main(filename){ open (filename) Read each line, remove the newline character, and build an array of the filenames written in (filename) for each file name of index i in the array, run doit(filename[i]), where i is a function equivalent to the script described above. } Now I can feed my script a list of all the potential problematic gcc source files, and for each one (i.e. file.c) with #if 0 statements, there will be a corresponding file (i.e file.c.if0s) with the instances recorded and indexed by line number. The next logical step, and one which I should be a hair away from having finished, is to make the script look at two different versions of the GCC source tree, and for each file in the trees, report the #if 0 statments that occur in both version's instance of the file. Thus, by comparing the latest GCC release with a much older release, one can compile a list of preprocessor if 0 statements which are very unlikely to be of any current relavence. It should be noted that there is a extra piece of functionality built into the script which I actually don't make use of in the case of #if 0 statements. I originally wrote the script to work with any specific if statement. It therefore is already capable of counting its position in the {, } tree of such if statements for deciding when it should be finished. With #if, #endif statements, this is pretty much unnecessary, but the script is easily adaptable to the purpose of finding any specific if statements (for example those which might involve an obsolete variable). For input like this, yada yada yada yada #if 0 yikes; if this code here; more code; #endif codecode lookatmycode #if 0 code1 code2 code33 1/3 #endif I get output like this: line number 3 #if 0 yikes; if this code here; more code; #endif line number 11 #if 0 code1 code2 code33 1/3 #endif ********************************************** A more interesting problem is the possibility of writing a script to automaticaly suggest a way of breaking up a source files. But the plan of action is less clear on this. I've been thinkin of ways for a script to try to isolate sections of code whose variables are local to that section, and creating separate functions of those sections. I'm very open to suggestions on ways to implement this kind of thing. It would be very cool, and even quite useful, I think. Regarding administrative details, I'm hoping to be worthy of credit by the end of this quarter. Once I am able to sign my life over to GNU, I can begin with contributing these scripts and changes they suggest (and I agree with). Later, Wes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.cs.uchicago.edu/pipermail/cs22800/attachments/20021118/320d3476/gcc_project_update.html From bsjohnso at midway.uchicago.edu Mon Nov 18 09:21:33 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] gcc update References: <3DD8B6AB.5070106@uchicago.edu> Message-ID: <3DD9057D.2090402@midway.uchicago.edu> I put Wes' info up in a new page with a link from the course page to it. Stephen, just let me know if you want me to create a page for you and put your e-mail in an "update" page. Otherwise I'll let you do what you want with getting it online. See ya, Ben -- Benjamin Johnson "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein From bsjohnso at midway.uchicago.edu Thu Nov 21 18:07:30 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Short Update Message-ID: <3DDD7542.1060304@midway.uchicago.edu> I tried my kernel module with a full FreeBSD 4.6.2 system (rather than one running in VMWare), and I still got it to crash in the same method. I guess that rules out VMWare. I'll update you all again this weekend. See ya, Ben -- Benjamin Johnson "I do not fear computers. I fear the lack of them." - Isaac Asimov From odonnell at cs.uchicago.edu Fri Nov 22 11:27:56 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Registration for free software practicum Message-ID: <20021122172801.CF03A8080A1@surya.cs.uchicago.edu> I just received a grade report sheet for this class, listing Stephen Dranger, Benjamin Johnson, Wesley Pegden, Samuel Tobin-Hochstadt. If this does not reflect the quarter in which you want to take credit, let's fix it right away. In any case, let's get some deadlines on the Web presentation. Mike O'D. From bsjohnso at midway.uchicago.edu Fri Nov 22 16:09:16 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Some success Message-ID: <3DDEAB0C.3030100@midway.uchicago.edu> I'm real close to determining the cause of my crashing... I have some stuff commented out and it no longer crashes in the manner I spoke of last monday. I'll update everyone later tonight. Thanks, Ben -- Benjamin Johnson "I do not fear computers. I fear the lack of them." - Isaac Asimov From bsjohnso at midway.uchicago.edu Fri Nov 22 23:37:54 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Well... Message-ID: <3DDF1432.60806@midway.uchicago.edu> Well I am even closer to determining what's wrong. However, since in my current code it seems to only crash after removing the module, and most likely a honeypot would never remove the module unless it was being taken down for analysis, I might as well move on and get this tweaked, packaged and work on the configuration / installation. I'll update you guys more this weekend and I'll update my development diary. Peace, Ben -- Benjamin Johnson "I do not fear computers. I fear the lack of them." - Isaac Asimov From bsjohnso at midway.uchicago.edu Sun Nov 24 11:31:39 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Bad News Message-ID: <3DE10CFB.9000502@midway.uchicago.edu> All, Lance's company decided to send him to California that week. He's sorry that he won't be able to make the December 4th meeting, but he's hoping to still come speak, possibly in January. Anyways, see you guys in class. Peace, Ben -- Benjamin Johnson "I do not fear computers. I fear the lack of them." - Isaac Asimov From bsjohnso at midway.uchicago.edu Sun Nov 24 23:14:54 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] Update Message-ID: <3DE1B1CE.8040204@midway.uchicago.edu> I'm moving ahead with trying to get my stuff ready to be released to other honeynet people for testing. I am having problems with compiling my monitoring part (that regularly checks /dev/sebek for data then encrypts it and spoofs addresses then sends it over the wire). I get these error messages to begin with: bash-2.05a# gcc -I/usr/lib/ -c sdm_utils.c -I./ In file included from sdm_utils.c:38: sdm_utils.h:113: warning: `struct libnet_link_int' declared inside parameter list sdm_utils.h:113: warning: its scope is only this definition or declaration, which is probably not what you want. sdm_utils.c: In function `open_socket': sdm_utils.c:154: `LIBNET_ERR_FATAL' undeclared (first use in this function) sdm_utils.c:154: (Each undeclared identifier is reported only once sdm_utils.c:154: for each function it appears in.) sdm_utils.c: At top level: sdm_utils.c:166: warning: `struct libnet_link_int' declared inside parameter list sdm_utils.c:166: conflicting types for `create_udp' sdm_utils.h:113: previous declaration of `create_udp' sdm_utils.c: In function `create_udp': sdm_utils.c:201: `PRu32' undeclared (first use in this function) sdm_utils.c:231: `PRu16' undeclared (first use in this function) sdm_utils.c:260: `LIBNET_IP_H' undeclared (first use in this function) sdm_utils.c:267: warning: passing arg 6 of `libnet_build_ethernet' from incompatible pointer type sdm_utils.c:267: too few arguments to function `libnet_build_ethernet' sdm_utils.c:277: warning: passing arg 3 of `libnet_build_udp' makes integer from pointer without a cast sdm_utils.c:277: too few arguments to function `libnet_build_udp' sdm_utils.c:280: `ETH_H' undeclared (first use in this function) sdm_utils.c:280: warning: passing arg 2 of `libnet_do_checksum' makes pointer from integer without a cast sdm_utils.c:280: too few arguments to function `libnet_do_checksum' sdm_utils.c:285: too few arguments to function `libnet_do_checksum' I remeber getting this error once when I installed sebek on my linux machine, although I cannot remember how I fixed it. I think it has something to do with libnet although I cannot remember what (and I have libnet installed on my freebsd machine). Any ideas? Thanks, Ben -- Benjamin Johnson "I do not fear computers. I fear the lack of them." - Isaac Asimov From sam at uchicago.edu Mon Nov 18 13:11:01 2002 From: sam at uchicago.edu (sam th) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] project status - AbiWord Message-ID: <1037646660.5863.12.camel@bur-jud-175-182.rh.uchicago.edu> Attached are two text files, one with an outline of the project plan, and one with a status update. Ben, if you could put these on the website, that would be great. Thanks -- sam th -------------- next part -------------- *CS22800 Project Description: AbiWord Compliance with the GNOME HIG ** About AbiWord AbiWord is a a cross-platform, free software word processor. On Unix/Linux platforms, it uses the GTK+ toolkit and the GNOME framework to render and present its user interfaces. AbiWord strives to integrate itself properly with each platform it appears on. This means providing the top-of-screen menu bar on Mac OS, adhering to Windows conventions on that platform, and complying with GNOME/GTK standards on Unix/Linux. More about AbiWord is available at http://www.abisource.com. ** About the GNOME Human Interface Guidelines (HIG) The GNOME HIG is a project to provide standards to make the GNOME project user interfaces consistent and easy to use across the entire GNOME platform. It consists in a set of guidelines that specify behavior for everything from window titles to application interoperability. The HIG ensures that GNOME applications have a consistent look and feel, and that they follow best practices for usability of software. More about the HIG is available at http://developer.gnome.org/projects/gup/hig ** AbiWord's compliance with the HIG AbiWord had initially fairly low compliance with the specific details of the HIG, although it followed many of the more general reccommendations. Dom Lachowicz, one of the principal AbiWord developers, has implemented a number of the reccomendations since the HIG was released. However, AbiWord still has a ways to go on this front. ** My plan of action *** HIG understanding The first step is to understand the reccomendations of the GNOME HIG and the rationale behind them. This requires reading the HIG, of course, and also the sources that it draws on, such as the Apple Aqua Interface Guidelines, on which the GNOME HIG was largely modeled. *** AbiWord evaluation AbiWord must be evaluated for its compliance with the HIG. This will take the form of filing bugs in BugZilla, the AbiWord bug tracking system, which will keep track of the all the outstanding issues with respect to compliance with the HIG. More about Bugzilla is available at http://bugzilla.abisource.com. Additionally, I plan to talk to members of the GNOME Usability team about their opinions of AbiWord usability, and ask them for a comprehensive UI review, which they are in the process of doing for many GNOME applications. *** Bug fixing After the bugs have been identified, they must then be fixed. I will be doing the majority of this work, however, since this is a free software project, and the BugZilla database is public, other developers can also work on this phase of the project. -------------- next part -------------- * Current Status of Project ** HIG Understanding This portion of the project is basically completed. I have looked at the HIG and its reccommendations, and discussed some of them with the GNOME Usability team. ** Evaluation This portion is mostly done. I have filed a large number of bugs on the subject of the HIG in the AbiWord Bugzilla database. They can be seen by looking at Bug #4142 [1] and its dependencies, which are all the bugs that I have filed on the subject. I have asked the GNOME Usability team for a review, but they have not yet responded. The email was CCed to the class mailing list. ** Bug Fixing This portion is still in progress. I have fixed some bugs, such as 4144 and 4146, and others have fixed other bugs, such as 4145. However, a number of bugs are still open. I intend to continue working on fixing these. [1] http://bugzilla.abisource.com/show_bug.cgi?id=4142 From sam at uchicago.edu Mon Nov 18 13:07:23 2002 From: sam at uchicago.edu (sam th) Date: Thu May 18 12:41:35 2006 Subject: [Cs22800] request for UI review Message-ID: <1037646442.5863.9.camel@bur-jud-175-182.rh.uchicago.edu> I'm currently working on improving the UI of AbiWord to comply with the GNOME HIG, and usability principles in general. It would be of great help if people on the usability team were willing to perform a UI review for AbiWord. I would be willing to meet on #ui-review at a convenient time for the UI team, if that would help. Thanks -- sam th