Re: [9fans] osx 9p client?
not yet... On Feb 1, 2008, at 1:19 PM, Steve Simon wrote: I assume I would have heard but just in case... has anyone written a p9 client for osx? I need somthing which integrates into osx and the Finder cleanly, storing its key in the OSX keychain. I understand that I may be able to get command line access with p9p and MacFuse but I was hoping for a simple gui client (its not for me ☺). -Steve
Re: [9fans] A newbie question...
* Filipp Andronov <[EMAIL PROTECTED]> wrote: > Some graphics chip, actually i want port OpenGL to Plan9, > but DRI hasugly architecture and Mesa with X11 are overload > by unnecessary code,as far as i know it is because of historical > reasons. ACK. 3D stuff on *nix is very fat. I wouldn't suggest porting the whole thing, but just leaving the client API. Maybe you could start with specifying an synthetic filesystem which provides the client side functionality, so it's easy to develop an libGL replacement upon that. Feel free to use the OSS-QM resources (eg. the wiki) for that :) BTW: I'm currently doing similar things on the audio front. Maybe you've already seen my posting on the mixer-fs. I'm also working on an Audio-IO-FS. This one should provide an platform and device agnostic interface to audio io devices, so all these APIs out there (alsa userland, esound, ...) can become small and simple adapters to it. > I have experience with X11 and OpenGL specifications and device > driver development, so my plan was port general parts of mesa > (not all of course), but with out DRI on Intel graphics chip > (i have that card) with hardware acceleration. DRI is something which should be far hidden behind clients not even exist within within an client process. AFAIK it's far from being portable (but maybe I'm wrong). > When i start dig problem i have found DRI replacement known as > Gallium3D, it is completely new project (from Mesa community as > far asi know) and it small enough for try to port it. I don't have any experience with this. But from a quick look it might be worth thinking of. Maybe you could start modeling the API's functionality into an filesystem. As an intermediate step you could develop an server for this (maybe using libmixp) on *nix/GNU platforms and connect it from an Plan9 environment (either remotely or from plan9port). So you can develop the Plan9 userland side w/o having the actual drivers ported to Plan9. Once this works and the interface specs are fixed, you could move to native Plan9. At least that's the way *I* would go. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] new 9load report
> hello, > > I tried the 5th of November iso (which I guess uses the new 9load) and > here goes the report: > > PBS1... Plan 9 from Bell Labs > ELCR: 0C00 > Initial probe, to find plan9.ini... dev A0 port 1F0 config 85C0 > capabilities 0F00 mwdma 0407 > pcirouting 8086/27DF at pin 1 irq 10 > dev A0 port 18D0 config 045A capabilities 2F00 mwdma 0007 udma 203F > LLBA sectors 117231408 > ahci0 port 0xd4544400: hba sss 0; ncs 31; coal 0; mports 3; led 1; clo 1; ems > 0; > > intel 63[12]xesb: sata-I ports with 2 ports > FLAGS=10282 TRAP=e ECODE=0 PC=8002a3a0 >AX f000ff6b BX 80039f64 CX f000ff53 DX 03d5 >SI 80037e50 DI 0002 BP 0008 >CS 0010 DS 0008 ES 0008 FS 0008 GS 0008 >CR0 8011 CR2 f000ff6b CR3 c000 > panic: exception/interrupt 14 in reviewing my email i found this unfinished business. i believe this bug in the ahci driver has been fixed and is in current releases. it was my fault. - erik
Re: [9fans] A newbie question...
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Plan 9 becomes the proof thereof, if autotools were as successful as > claimed, it ought to be trivial to port them to a different platform. > It isn't, nor is it necessary. In porting the code for libtiff and > geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools, > png, gd and eventually libtiff and geotiff. The sum total of these > mkfiles is probably less than two thousand lines. But it is > impossible to feed these back to the developers, because they do not > fit into their philosophical scheme. Feel free to post the patches to the OSS-QM project: http://oss-qm.metux.de/ cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] A newbie question...
* Pawe?? Lasek <[EMAIL PROTECTED]> wrote: > The best thing about autotools is I think the scheme of running > configure - AFAIK mplayer doesn't even use configure for it's script, > instead > they use their own, which looks the same to end user. And saves a lot > of time :-) ACK. The fact that there's such an script with an standardized command line interface is quite good. I which there were more packages providing this interface (instead there a lots of packages providing an ./configure script which isn't only incompatible but even more crap than autoconf stuff, eg. Perl's). BTW: mplayer's configure script is hand-written (in principle a good thing ;-p), but it's incompatible with the GNU style. Rich Felker's comment on this: "we dont want people to mix it up with this autoconf crap" Last time I checked, it also didn't make consequent use of pkg-config (but used it a few times). Rich Felker's comment: "we dont want to require this pkg-config crap" well ... cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] A newbie question...
* erik quanstrom <[EMAIL PROTECTED]> wrote: > part of the issue is that autotool solves a problem that doesn't > exist on plan 9 systems. one doesn't need to test for compilers, > exotic library problems or portability issues. Actually, often for problems that don't exist at all (on sane systems). For example, why each individual package should check for the toolchain commands ?! That's completely insane! There are standard variables for that, which can be assumed to point to the right commands. Checking if the toolchain's not broken should clealy NOT be the job of an individual package. Another point are imported libraries: there's really no need to run any compile test (or even worse: try to run some code). Just ask an database tool (->pkg-config) to tell you the right flags and make sure the required version is installed. Yeah, there are working autoconf macros for that, but many many packages still don't use them (sometimes with really stupid cop-out's ;-o) Older versions of autoconf had been even more insane: Lot's of "detection" macros (X11 stuff was such an bad candidate) pulled in hard-coded and absolute (!) pathes. It's obvious that this clearly breaks any crosscompile attemt. BTW: one thing I never understood in the autoconf world: Why's the term "support" so badly abused ?! Imagine: in many packages you can switch whether some other package is used - they call this "supported". For example I'm currently compiling VLC: there's an flag for "gnutls" support. WTH shall this mean ?! The right way would be an "enable TLS" option, stating this requires GNU-TLS as dependency. Seems like autoconf people tend to turn things upside down ;-O > another problem with autoconf is it encourages a style of > programming that exploits every last nook and cranny of > a system's & compiler's capabilities when the vast majority > of applications will do just fine with the least common > denominator. if one's goal is to run on a variety of unix > systems, this just is poor engineering. As already said: autoconf has *NOTHING* to do with real portability, just working around lots of system/target differences. ACK, this is really poor engineering. > as a case in point, my sacrificial linux machine is a 993mhz > pIII. mplayer, an application one would think would benefit > from fancy optimizations on such a slow machine, shows absolutely > no visible performance benefit from sse2 instructions. it > is fast enough already. Well, I'm really happy with those optimizations (eg. on number crunching applications, properly optimized code *can* give an heaviy boost). But there's really *no* need for such an complex and unstable oracle like autoconf - there are clean ways to fix this, eg. passing the right CFLAGS and using the compiler's/preprocessor's symbols. > one last gripe: autotools often take longer to ./configure > than to compile with gcc. curious that gcc is famed for > slowness. Yep, *rofl* ;-O cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] A newbie question...
On 2008-Feb-3, at 17:19 , Enrico Weigelt wrote: One of the major problem of autoconf is that It tries to guess around lots of things, and this often fails or is very unclean (it requires *really great* care to produce good code with it). In fact this has nothing to do with portable programming, but working around uncountable of target specifics. Autoconf is nothing but a stinking rotten corpse that lives only because the cult of GNU adherents cannot (no, refuse to) grok the concept of POSIX. The last time I ever had the requirement to use 'configure' -- that's 'configure', not 'autoconf' in all its splendor -- was circa 1992. And that was solely thanks to Sun unbundling the C compiler, leading to the insane collection of command invocations needed to build something as simple as cat.c.
Re: [9fans] A newbie question...
* Filipp Andronov <[EMAIL PROTECTED]> wrote: Hi, > And the first one looks like this: does GNU build system (autoconf, > automake, e.t.c) has been ported in Plan9? Or maybe there is some > alternative? :) If you got Java running, you might risk a look at unitool and treebuild: * http://unitool.metux.de/ * http://treebuild.metux.de/ One of the major problem of autoconf is that It tries to guess around lots of things, and this often fails or is very unclean (it requires *really great* care to produce good code with it). In fact this has nothing to do with portable programming, but working around uncountable of target specifics. Unitool goes an different approach: real abstraction with clear and *strict* interfaces. The individual target configuration is now the job of unitool and the one who sets it up - not the job of an individual application. For example it provides an target/platform agnostic toolchain interface - there is now only ONE way to call the toolchain, no matter what target you're building for and which toolchain you're actually using. Another big problem of most buildsystems (including all make-based) is they're modeling rules for building instead of the software's structure. Treebuild goes an different approach: modeling just the structure of certain package, leaving the build process itself out of scope of the package. > I want port some software from linux to Plan9, but couldn't find any > documentation about how i should do this in "plan9 style" ) hmm, "plan9 style" ? Maybe a few hints: * keep the code simple * common things belong to their own libs * autonomous things belong to their own fileserver What packages are you going to port ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] A newbie question...
A perfect example: Windows security! :-) On Feb 3, 2008, at 8:02 PM, Enrico Weigelt wrote: * Uriel <[EMAIL PROTECTED]> wrote: Autotools badness is way beyond most peoples wildest imagination... Actually, It helped me enlarging my imagination capabilities ;-P BTW: there are even far worse things out there ;-O cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] A newbie question...
* Uriel <[EMAIL PROTECTED]> wrote: > Autotools badness is way beyond most peoples wildest imagination... Actually, It helped me enlarging my imagination capabilities ;-P BTW: there are even far worse things out there ;-O cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] A newbie question...
* Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > > On Jan 31, 2008, at 7:22 PM, Michael Andronov wrote: > > >Hi, > > > >I'm a new to Plan9, and I am trying to understand the current > >status of the system. > >In particular, I am wondering about the list of application available= > >- is there email reader? > > Several ways to do this, but to set up: > http://plan9.bell-labs.com/wiki/plan9/Mail_configuration/index.html BTW: I'm currently designing an new mail filesystem which should should allow directly mounting many kind of mail storages and similar things (eg. rss-feeds, nttp-servers, etc, etc). http://oss-qm.metux.de/index.php/9forge/mailfs-ng Maybe you'd like to help a bit :) > >In other words, I am wondering if it is possible to switch to Plan > >9 system, and to use it as 'everyday machine'? Actually, I'm personally not using native Plan9 at all. Instead I'm very interested in doing things the "Plan9-way" on *nix platforms. (eg. using synthethic filesystems for a lot of things and splitting large applications into smaller, independent parts, speaking 9P). BTW: plan9port allows building/running Plan9 programs on *nix systems (eg Linux). Always woth to look at :) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] A newbie question...
C++ has not been included in Plan 9 since the third edition, but the source code is available, and Steve Simon has made some updates. Once you have abaco the way I said to get it, you also have Federico Benavento's contrib system. With it, all you need is contrib/install steve/cfront Otherwise, get contrib with /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib and then do the above. Then, to compile a C++ program: c++/8c x.C # considering .C is the C++ extension c++/8l -o x x.8 The one thing: don't use #include using namespace std; You will need #include which does that for you. On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote: > Another question from newbie : > > I have noticed some discussion(s) on Internet about C++ language > for Plan9; > I'm wondering what is a bottom line of the story: > - is there a C++ compiler? Any plans for it? > - has it been 'banned' from Plan9? > - has gcc been ported to Plan9? ( as was suggested in one of the > messages I saw)... > > Thank for your attention. > Michael. >
[9fans] RFC: 9P Mixer Filesystem
Hi folks, here's an proposal for an 9P-based mixer control filesystem: * http://j.metux.de/index.php?option=com_content&task=view&id=50 Comments/suggestions appreciated :) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] CUPS printing
It looks like OSX enables lpd printing when you share a printer on the network - I just added an entry for that IP address and queue name of the print & it worked! Thanks for helping Keith On 3 Feb 2008, at 18:43, Steve Simon wrote: I've got a question that you might be able to answer - I've just installed Plan9 on Parallels and I've got the networking set up OK. Now I want to set up a printer - I've got a HP deskjet printer attached to an OSX server (so I could connect to it via CUPS or SAMBA) - is there anyway to get Plan9 to print to it forsyth wrote an smb printing client many years ago, I am pretty sure I have a copy somwhere if its no longer on the net. Alternatively I would suggest you enable lpr/lpd printing on the OSX server which plan9 supports out of the box. see the lp(8) and /sys/doc/lp.8 -Steve
Re: [9fans] CUPS printing
> I've got a question that you might be able to answer - I've just > installed Plan9 on Parallels and I've got the networking set up > OK. Now I want to set up a printer - I've got a HP deskjet printer > attached to an OSX server (so I could connect to it via CUPS or > SAMBA) - is there anyway to get Plan9 to print to it forsyth wrote an smb printing client many years ago, I am pretty sure I have a copy somwhere if its no longer on the net. Alternatively I would suggest you enable lpr/lpd printing on the OSX server which plan9 supports out of the box. see the lp(8) and /sys/doc/lp.8 -Steve
Re: [9fans] A newbie question...
Just in this minute i'm trying to start Plan9 in VMWare :D 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > Okay, that's fine. What I'm saying is that you don't have to write > something from scratch to get something else working. If you actually > do get one of the other OpenGL implementations to work, then porting > Gallium3D is a lot easier. > > Either way, you won't need direct hardware manipulation on Plan 9. > Just run it from a virtual machine and see where you go from there. > > On Feb 3, 2008, at 11:33 AM, Filipp Andronov wrote: > > >> There were many attempts to port OpenGL to Plan 9, none of which I > >> got to work. I started working on a ground-up 3D library but lost it > >> to a faulty Plan 9 partition. > > I have no plan to start serious works about OpenGL porting. I just > > want to play with Plan9, if i port Gallium3D if will be great success. > > > > Actually i have no working Plan9 yet (!), so i just looking around, > > reading documentation and asking about some questions that i have in > > my mind :) > > > > So my plans is not something serious, i just looking for somethings > > for fun :) > > > > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > >> There were many attempts to port OpenGL to Plan 9, none of which I > >> got to work. I started working on a ground-up 3D library but lost it > >> to a faulty Plan 9 partition. > >> > >> On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote: > >> > >>> Some graphics chip, actually i want port OpenGL to Plan9, but DRI > >>> has > >>> ugly architecture and Mesa with X11 are overload by unnecessary > >>> code, > >>> as far as i know it is because of historical reasons. > >>> > >>> I have experience with X11 and OpenGL specifications and device > >>> driver > >>> development, so my plan was port general parts of mesa (not all of > >>> course), but with out DRI on Intel graphics chip (i have that card) > >>> with hardware acceleration. > >>> When i start dig problem i have found DRI replacement known as > >>> Gallium3D, it is completely new project (from Mesa community as > >>> far as > >>> i know) and it small enough for try to port it. Intel chips has very > >>> good documentation and linux driver what i know very well. So plan > >>> was: > >>> 1. Port Gallium3D, pieces by piece > >>> 2. Port some features from Linux Intel driver to Plan9 if necessary > >>> 3. Try to port some pieces Mesa > >>> > >>> Of course it is a very big work, and i know that, but it is > >>> interesting enough to be fun. I have no target to create completely > >>> OpenGL implementation or port of Mesa, i just want to play with > >>> Plan9 > >>> kernel, Mesa and Intel card :)) > >>> > >>> 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > Out of curiosity, what hardware do you need to get working? > > On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote: > > > I'm not sure that "project fork" is a best way. Because hardware > > problem is a little piece of work and it's lays it separate > > module. > > The biggest part of application is a some computations and some > > algorithms implementation...As far, as application was port in > > many > > different Linux platforms, it's almost impossible to find some > > function with out #ifdef :)) > > > > Ok, any way, it looks like "project fork" is simplest way to do > > port, > > so any other waysis not very interesting. I think that this > > way is > > most correct, because in that case i could redesign many parts of > > this > > application in "plan9 style", do some soft services like, files > > for > > example :) > > > > Thanks to all for your help :) > > > > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > >> You need to do direct hardware manipulation? Then "project > >> fork" is > >> probably best. > >> > >> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: > >> > >>> Heh, i try to "port" my program, and it's really not possible > >>> in my > >>> point of view :) > >>> > >>> Actually, i don't have working Plan9 right now, reason is quite > >>> simple, on my hardware plan9 does do not work (PC emulators > >>> couldn't > >>> help because my program should work with some special hardware), > >>> so i > >>> try to create PC from "supported hardware" list, but it take > >>> some > >>> time to get all pieces, put they together, install, configure > >>> plan9 > >>> and so on )) > >>> Ok, i have no Plan9, but i have my application that i want to > >>> port, > >>> so i try to remove all autotools macros from it and try to do > >>> some > >>> preparations, like new abstraction layer for threads > >>> creation...and > >>> i'm completely failed, just because too much autotools stuff in > >>> sources. And it too complicated to figure out what exactly i > >>> should > >>> remove in every case... > >>> A
Re: [9fans] A newbie question...
Okay, that's fine. What I'm saying is that you don't have to write something from scratch to get something else working. If you actually do get one of the other OpenGL implementations to work, then porting Gallium3D is a lot easier. Either way, you won't need direct hardware manipulation on Plan 9. Just run it from a virtual machine and see where you go from there. On Feb 3, 2008, at 11:33 AM, Filipp Andronov wrote: There were many attempts to port OpenGL to Plan 9, none of which I got to work. I started working on a ground-up 3D library but lost it to a faulty Plan 9 partition. I have no plan to start serious works about OpenGL porting. I just want to play with Plan9, if i port Gallium3D if will be great success. Actually i have no working Plan9 yet (!), so i just looking around, reading documentation and asking about some questions that i have in my mind :) So my plans is not something serious, i just looking for somethings for fun :) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: There were many attempts to port OpenGL to Plan 9, none of which I got to work. I started working on a ground-up 3D library but lost it to a faulty Plan 9 partition. On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote: Some graphics chip, actually i want port OpenGL to Plan9, but DRI has ugly architecture and Mesa with X11 are overload by unnecessary code, as far as i know it is because of historical reasons. I have experience with X11 and OpenGL specifications and device driver development, so my plan was port general parts of mesa (not all of course), but with out DRI on Intel graphics chip (i have that card) with hardware acceleration. When i start dig problem i have found DRI replacement known as Gallium3D, it is completely new project (from Mesa community as far as i know) and it small enough for try to port it. Intel chips has very good documentation and linux driver what i know very well. So plan was: 1. Port Gallium3D, pieces by piece 2. Port some features from Linux Intel driver to Plan9 if necessary 3. Try to port some pieces Mesa Of course it is a very big work, and i know that, but it is interesting enough to be fun. I have no target to create completely OpenGL implementation or port of Mesa, i just want to play with Plan9 kernel, Mesa and Intel card :)) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: Out of curiosity, what hardware do you need to get working? On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote: I'm not sure that "project fork" is a best way. Because hardware problem is a little piece of work and it's lays it separate module. The biggest part of application is a some computations and some algorithms implementation...As far, as application was port in many different Linux platforms, it's almost impossible to find some function with out #ifdef :)) Ok, any way, it looks like "project fork" is simplest way to do port, so any other waysis not very interesting. I think that this way is most correct, because in that case i could redesign many parts of this application in "plan9 style", do some soft services like, files for example :) Thanks to all for your help :) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: You need to do direct hardware manipulation? Then "project fork" is probably best. On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: Heh, i try to "port" my program, and it's really not possible in my point of view :) Actually, i don't have working Plan9 right now, reason is quite simple, on my hardware plan9 does do not work (PC emulators couldn't help because my program should work with some special hardware), so i try to create PC from "supported hardware" list, but it take some time to get all pieces, put they together, install, configure plan9 and so on )) Ok, i have no Plan9, but i have my application that i want to port, so i try to remove all autotools macros from it and try to do some preparations, like new abstraction layer for threads creation...and i'm completely failed, just because too much autotools stuff in sources. And it too complicated to figure out what exactly i should remove in every case... And my application much smaller that mesa for example. Or X11 (by the way, how X11 was ported?), and i do not touсh such problems like different library, kernel interfaces and so, and so... So it looks like "project fork" is only way :( 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: Circular cause and consequence is funny. Let me add to this list: - jpg - png - tiff - PostScript - TeX (tpic) - HTML - Mahjongg, sokoban, sudoku, tetris (games/4s) - SPARC, MIPS, x64 - MP3, PCM, OGG (PAC was made at Bell Labs) - SoundBlaster 16 Let me put it this way: GNU software is good, except for GNU development tools, which, except for the gcc program itself, are mediocre and break compatibility (try using a Bell Labs makefile with GNU make).
Re: [9fans] A newbie question...
> There were many attempts to port OpenGL to Plan 9, none of which I > got to work. I started working on a ground-up 3D library but lost it > to a faulty Plan 9 partition. I have no plan to start serious works about OpenGL porting. I just want to play with Plan9, if i port Gallium3D if will be great success. Actually i have no working Plan9 yet (!), so i just looking around, reading documentation and asking about some questions that i have in my mind :) So my plans is not something serious, i just looking for somethings for fun :) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > There were many attempts to port OpenGL to Plan 9, none of which I > got to work. I started working on a ground-up 3D library but lost it > to a faulty Plan 9 partition. > > On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote: > > > Some graphics chip, actually i want port OpenGL to Plan9, but DRI has > > ugly architecture and Mesa with X11 are overload by unnecessary code, > > as far as i know it is because of historical reasons. > > > > I have experience with X11 and OpenGL specifications and device driver > > development, so my plan was port general parts of mesa (not all of > > course), but with out DRI on Intel graphics chip (i have that card) > > with hardware acceleration. > > When i start dig problem i have found DRI replacement known as > > Gallium3D, it is completely new project (from Mesa community as far as > > i know) and it small enough for try to port it. Intel chips has very > > good documentation and linux driver what i know very well. So plan > > was: > > 1. Port Gallium3D, pieces by piece > > 2. Port some features from Linux Intel driver to Plan9 if necessary > > 3. Try to port some pieces Mesa > > > > Of course it is a very big work, and i know that, but it is > > interesting enough to be fun. I have no target to create completely > > OpenGL implementation or port of Mesa, i just want to play with Plan9 > > kernel, Mesa and Intel card :)) > > > > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > >> Out of curiosity, what hardware do you need to get working? > >> > >> On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote: > >> > >>> I'm not sure that "project fork" is a best way. Because hardware > >>> problem is a little piece of work and it's lays it separate module. > >>> The biggest part of application is a some computations and some > >>> algorithms implementation...As far, as application was port in many > >>> different Linux platforms, it's almost impossible to find some > >>> function with out #ifdef :)) > >>> > >>> Ok, any way, it looks like "project fork" is simplest way to do > >>> port, > >>> so any other waysis not very interesting. I think that this > >>> way is > >>> most correct, because in that case i could redesign many parts of > >>> this > >>> application in "plan9 style", do some soft services like, files for > >>> example :) > >>> > >>> Thanks to all for your help :) > >>> > >>> 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > You need to do direct hardware manipulation? Then "project fork" is > probably best. > > On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: > > > Heh, i try to "port" my program, and it's really not possible > > in my > > point of view :) > > > > Actually, i don't have working Plan9 right now, reason is quite > > simple, on my hardware plan9 does do not work (PC emulators > > couldn't > > help because my program should work with some special hardware), > > so i > > try to create PC from "supported hardware" list, but it take some > > time to get all pieces, put they together, install, configure > > plan9 > > and so on )) > > Ok, i have no Plan9, but i have my application that i want to > > port, > > so i try to remove all autotools macros from it and try to do some > > preparations, like new abstraction layer for threads > > creation...and > > i'm completely failed, just because too much autotools stuff in > > sources. And it too complicated to figure out what exactly i > > should > > remove in every case... > > And my application much smaller that mesa for example. Or X11 (by > > the > > way, how X11 was ported?), and i do not touсh such problems like > > different library, kernel interfaces and so, and so... > > > > So it looks like "project fork" is only way :( > > > > 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: > >> On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> > >> wrote: > >>> Circular cause and consequence is funny. Let me add to this > >>> list: > >>> - jpg > >>> - png > >>> - tiff > >>> - PostScript > >>> - TeX (tpic) > >>> - HTML > >>> - Mahjongg, sokoban, sudoku, tetris (games/4s) > >>> - SPARC, MIPS, x64 > >>> - MP3, PCM, OGG (PAC was made at Bell Labs) > >>> - SoundBlaster 16 > >>> > >>> Let me put it this way: > >>>
Re: [9fans] A newbie question...
There were many attempts to port OpenGL to Plan 9, none of which I got to work. I started working on a ground-up 3D library but lost it to a faulty Plan 9 partition. On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote: Some graphics chip, actually i want port OpenGL to Plan9, but DRI has ugly architecture and Mesa with X11 are overload by unnecessary code, as far as i know it is because of historical reasons. I have experience with X11 and OpenGL specifications and device driver development, so my plan was port general parts of mesa (not all of course), but with out DRI on Intel graphics chip (i have that card) with hardware acceleration. When i start dig problem i have found DRI replacement known as Gallium3D, it is completely new project (from Mesa community as far as i know) and it small enough for try to port it. Intel chips has very good documentation and linux driver what i know very well. So plan was: 1. Port Gallium3D, pieces by piece 2. Port some features from Linux Intel driver to Plan9 if necessary 3. Try to port some pieces Mesa Of course it is a very big work, and i know that, but it is interesting enough to be fun. I have no target to create completely OpenGL implementation or port of Mesa, i just want to play with Plan9 kernel, Mesa and Intel card :)) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: Out of curiosity, what hardware do you need to get working? On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote: I'm not sure that "project fork" is a best way. Because hardware problem is a little piece of work and it's lays it separate module. The biggest part of application is a some computations and some algorithms implementation...As far, as application was port in many different Linux platforms, it's almost impossible to find some function with out #ifdef :)) Ok, any way, it looks like "project fork" is simplest way to do port, so any other waysis not very interesting. I think that this way is most correct, because in that case i could redesign many parts of this application in "plan9 style", do some soft services like, files for example :) Thanks to all for your help :) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: You need to do direct hardware manipulation? Then "project fork" is probably best. On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: Heh, i try to "port" my program, and it's really not possible in my point of view :) Actually, i don't have working Plan9 right now, reason is quite simple, on my hardware plan9 does do not work (PC emulators couldn't help because my program should work with some special hardware), so i try to create PC from "supported hardware" list, but it take some time to get all pieces, put they together, install, configure plan9 and so on )) Ok, i have no Plan9, but i have my application that i want to port, so i try to remove all autotools macros from it and try to do some preparations, like new abstraction layer for threads creation...and i'm completely failed, just because too much autotools stuff in sources. And it too complicated to figure out what exactly i should remove in every case... And my application much smaller that mesa for example. Or X11 (by the way, how X11 was ported?), and i do not touсh such problems like different library, kernel interfaces and so, and so... So it looks like "project fork" is only way :( 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: Circular cause and consequence is funny. Let me add to this list: - jpg - png - tiff - PostScript - TeX (tpic) - HTML - Mahjongg, sokoban, sudoku, tetris (games/4s) - SPARC, MIPS, x64 - MP3, PCM, OGG (PAC was made at Bell Labs) - SoundBlaster 16 Let me put it this way: GNU software is good, except for GNU development tools, which, except for the gcc program itself, are mediocre and break compatibility (try using a Bell Labs makefile with GNU make). I'd add to it the fact that autotools source files are hard to make, so many people who are to lazy to do it properly just put the famous (in)sanity check and checks for libs they use. The effect? A simple C program that doesn't rely on anything except for example libpng will check for C, C++, FORTRAN 77 compilers, check if those are from GCC and various other things. Imagine my surprise when I had seen a configure script (for EmacsLisp utility) that only checked for Emacs version and few EmacsLisp files it used - a rare thing IMHO, when >80% of configure running time is for checking for not used software. "CPU cycles are cheap, programmer time is expensive" <--- This doesn't mean that total laziness is appropriate. The best thing about autotools is I think the scheme of running configure - AFAIK mplayer doesn't even use configure for it's script, instead they use their own, which looks the same to end user. And saves a lot of time :-) -- Paul Lasek
Re: [9fans] A newbie question...
it would help to have intel and amd drivers based on published documentation. i don't have the amd (ati) link handy, but here's the link matt offered the other day: http://intellinuxgraphics.org/documentation.html - erik
Re: [9fans] A newbie question...
2008/2/3, Filipp Andronov <[EMAIL PROTECTED]>: > Some graphics chip, actually i want port OpenGL to Plan9, but DRI has > ugly architecture and Mesa with X11 are overload by unnecessary code, > as far as i know it is because of historical reasons. > > I have experience with X11 and OpenGL specifications and device driver > development, so my plan was port general parts of mesa (not all of > course), but with out DRI on Intel graphics chip (i have that card) > with hardware acceleration. > When i start dig problem i have found DRI replacement known as > Gallium3D, it is completely new project (from Mesa community as far as > i know) and it small enough for try to port it. Intel chips has very > good documentation and linux driver what i know very well. So plan > was: > 1. Port Gallium3D, pieces by piece > 2. Port some features from Linux Intel driver to Plan9 if necessary > 3. Try to port some pieces Mesa > > Of course it is a very big work, and i know that, but it is > interesting enough to be fun. I have no target to create completely > OpenGL implementation or port of Mesa, i just want to play with Plan9 > kernel, Mesa and Intel card :)) > > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > > Out of curiosity, what hardware do you need to get working? > > > > On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote: > > > > > I'm not sure that "project fork" is a best way. Because hardware > > > problem is a little piece of work and it's lays it separate module. > > > The biggest part of application is a some computations and some > > > algorithms implementation...As far, as application was port in many > > > different Linux platforms, it's almost impossible to find some > > > function with out #ifdef :)) > > > > > > Ok, any way, it looks like "project fork" is simplest way to do port, > > > so any other waysis not very interesting. I think that this way is > > > most correct, because in that case i could redesign many parts of this > > > application in "plan9 style", do some soft services like, files for > > > example :) > > > > > > Thanks to all for your help :) > > > > > > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > > >> You need to do direct hardware manipulation? Then "project fork" is > > >> probably best. > > >> > > >> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: > > >> > > >>> Heh, i try to "port" my program, and it's really not possible in my > > >>> point of view :) > > >>> > > >>> Actually, i don't have working Plan9 right now, reason is quite > > >>> simple, on my hardware plan9 does do not work (PC emulators couldn't > > >>> help because my program should work with some special hardware), > > >>> so i > > >>> try to create PC from "supported hardware" list, but it take some > > >>> time to get all pieces, put they together, install, configure plan9 > > >>> and so on )) > > >>> Ok, i have no Plan9, but i have my application that i want to > > >>> port, > > >>> so i try to remove all autotools macros from it and try to do some > > >>> preparations, like new abstraction layer for threads creation...and > > >>> i'm completely failed, just because too much autotools stuff in > > >>> sources. And it too complicated to figure out what exactly i should > > >>> remove in every case... > > >>> And my application much smaller that mesa for example. Or X11 (by > > >>> the > > >>> way, how X11 was ported?), and i do not touсh such problems like > > >>> different library, kernel interfaces and so, and so... > > >>> > > >>> So it looks like "project fork" is only way :( > > >>> > > >>> 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: > > On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > > > Circular cause and consequence is funny. Let me add to this list: > > > - jpg > > > - png > > > - tiff > > > - PostScript > > > - TeX (tpic) > > > - HTML > > > - Mahjongg, sokoban, sudoku, tetris (games/4s) > > > - SPARC, MIPS, x64 > > > - MP3, PCM, OGG (PAC was made at Bell Labs) > > > - SoundBlaster 16 > > > > > > Let me put it this way: > > > GNU software is good, except for GNU development tools, > > > which, > > > except for the gcc program itself, are mediocre and break > > > compatibility (try using a Bell Labs makefile with GNU make). > > > > > > > I'd add to it the fact that autotools source files are hard to > > make, so > > many people who are to lazy to do it properly just put the famous > > (in)sanity check and checks for libs they use. The effect? > > > > A simple C program that doesn't rely on anything except for > > example libpng > > will check for C, C++, FORTRAN 77 compilers, check if those are > > from > > GCC and various other things. > > > > Imagine my surprise when I had seen a configure script (for > > EmacsLisp > > utility) that only checked for Emacs version > > and few EmacsLisp files it used - a rare th
Re: [9fans] A newbie question...
Some graphics chip, actually i want port OpenGL to Plan9, but DRI has ugly architecture and Mesa with X11 are overload by unnecessary code, as far as i know it is because of historical reasons. I have experience with X11 and OpenGL specifications and device driver development, so my plan was port general parts of mesa (not all of course), but with out DRI on Intel graphics chip (i have that card) with hardware acceleration. When i start dig problem i have found DRI replacement known as Gallium3D, it is completely new project (from Mesa community as far as i know) and it small enough for try to port it. Intel chips has very good documentation and linux driver what i know very well. So plan was: 1. Port Gallium3D, pieces by piece 2. Port some features from Linux Intel driver to Plan9 if necessary 3. Try to port some pieces Mesa Of course it is a very big work, and i know that, but it is interesting enough to be fun. I have no target to create completely OpenGL implementation or port of Mesa, i just want to play with Plan9 kernel, Mesa and Intel card :)) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > Out of curiosity, what hardware do you need to get working? > > On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote: > > > I'm not sure that "project fork" is a best way. Because hardware > > problem is a little piece of work and it's lays it separate module. > > The biggest part of application is a some computations and some > > algorithms implementation...As far, as application was port in many > > different Linux platforms, it's almost impossible to find some > > function with out #ifdef :)) > > > > Ok, any way, it looks like "project fork" is simplest way to do port, > > so any other waysis not very interesting. I think that this way is > > most correct, because in that case i could redesign many parts of this > > application in "plan9 style", do some soft services like, files for > > example :) > > > > Thanks to all for your help :) > > > > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > >> You need to do direct hardware manipulation? Then "project fork" is > >> probably best. > >> > >> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: > >> > >>> Heh, i try to "port" my program, and it's really not possible in my > >>> point of view :) > >>> > >>> Actually, i don't have working Plan9 right now, reason is quite > >>> simple, on my hardware plan9 does do not work (PC emulators couldn't > >>> help because my program should work with some special hardware), > >>> so i > >>> try to create PC from "supported hardware" list, but it take some > >>> time to get all pieces, put they together, install, configure plan9 > >>> and so on )) > >>> Ok, i have no Plan9, but i have my application that i want to > >>> port, > >>> so i try to remove all autotools macros from it and try to do some > >>> preparations, like new abstraction layer for threads creation...and > >>> i'm completely failed, just because too much autotools stuff in > >>> sources. And it too complicated to figure out what exactly i should > >>> remove in every case... > >>> And my application much smaller that mesa for example. Or X11 (by > >>> the > >>> way, how X11 was ported?), and i do not touсh such problems like > >>> different library, kernel interfaces and so, and so... > >>> > >>> So it looks like "project fork" is only way :( > >>> > >>> 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: > On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > > Circular cause and consequence is funny. Let me add to this list: > > - jpg > > - png > > - tiff > > - PostScript > > - TeX (tpic) > > - HTML > > - Mahjongg, sokoban, sudoku, tetris (games/4s) > > - SPARC, MIPS, x64 > > - MP3, PCM, OGG (PAC was made at Bell Labs) > > - SoundBlaster 16 > > > > Let me put it this way: > > GNU software is good, except for GNU development tools, > > which, > > except for the gcc program itself, are mediocre and break > > compatibility (try using a Bell Labs makefile with GNU make). > > > > I'd add to it the fact that autotools source files are hard to > make, so > many people who are to lazy to do it properly just put the famous > (in)sanity check and checks for libs they use. The effect? > > A simple C program that doesn't rely on anything except for > example libpng > will check for C, C++, FORTRAN 77 compilers, check if those are > from > GCC and various other things. > > Imagine my surprise when I had seen a configure script (for > EmacsLisp > utility) that only checked for Emacs version > and few EmacsLisp files it used - a rare thing IMHO, when >80% of > configure running time is for checking for not used > software. > > "CPU cycles are cheap, programmer time is expensive" <--- This > doesn't > mean that total laziness is appropriate. > > The bes
Re: [9fans] A newbie question...
Out of curiosity, what hardware do you need to get working? On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote: I'm not sure that "project fork" is a best way. Because hardware problem is a little piece of work and it's lays it separate module. The biggest part of application is a some computations and some algorithms implementation...As far, as application was port in many different Linux platforms, it's almost impossible to find some function with out #ifdef :)) Ok, any way, it looks like "project fork" is simplest way to do port, so any other waysis not very interesting. I think that this way is most correct, because in that case i could redesign many parts of this application in "plan9 style", do some soft services like, files for example :) Thanks to all for your help :) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: You need to do direct hardware manipulation? Then "project fork" is probably best. On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: Heh, i try to "port" my program, and it's really not possible in my point of view :) Actually, i don't have working Plan9 right now, reason is quite simple, on my hardware plan9 does do not work (PC emulators couldn't help because my program should work with some special hardware), so i try to create PC from "supported hardware" list, but it take some time to get all pieces, put they together, install, configure plan9 and so on )) Ok, i have no Plan9, but i have my application that i want to port, so i try to remove all autotools macros from it and try to do some preparations, like new abstraction layer for threads creation...and i'm completely failed, just because too much autotools stuff in sources. And it too complicated to figure out what exactly i should remove in every case... And my application much smaller that mesa for example. Or X11 (by the way, how X11 was ported?), and i do not touсh such problems like different library, kernel interfaces and so, and so... So it looks like "project fork" is only way :( 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: Circular cause and consequence is funny. Let me add to this list: - jpg - png - tiff - PostScript - TeX (tpic) - HTML - Mahjongg, sokoban, sudoku, tetris (games/4s) - SPARC, MIPS, x64 - MP3, PCM, OGG (PAC was made at Bell Labs) - SoundBlaster 16 Let me put it this way: GNU software is good, except for GNU development tools, which, except for the gcc program itself, are mediocre and break compatibility (try using a Bell Labs makefile with GNU make). I'd add to it the fact that autotools source files are hard to make, so many people who are to lazy to do it properly just put the famous (in)sanity check and checks for libs they use. The effect? A simple C program that doesn't rely on anything except for example libpng will check for C, C++, FORTRAN 77 compilers, check if those are from GCC and various other things. Imagine my surprise when I had seen a configure script (for EmacsLisp utility) that only checked for Emacs version and few EmacsLisp files it used - a rare thing IMHO, when >80% of configure running time is for checking for not used software. "CPU cycles are cheap, programmer time is expensive" <--- This doesn't mean that total laziness is appropriate. The best thing about autotools is I think the scheme of running configure - AFAIK mplayer doesn't even use configure for it's script, instead they use their own, which looks the same to end user. And saves a lot of time :-) -- Paul Lasek
Re: [9fans] A newbie question...
I'm not sure that "project fork" is a best way. Because hardware problem is a little piece of work and it's lays it separate module. The biggest part of application is a some computations and some algorithms implementation...As far, as application was port in many different Linux platforms, it's almost impossible to find some function with out #ifdef :)) Ok, any way, it looks like "project fork" is simplest way to do port, so any other waysis not very interesting. I think that this way is most correct, because in that case i could redesign many parts of this application in "plan9 style", do some soft services like, files for example :) Thanks to all for your help :) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > You need to do direct hardware manipulation? Then "project fork" is > probably best. > > On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: > > > Heh, i try to "port" my program, and it's really not possible in my > > point of view :) > > > > Actually, i don't have working Plan9 right now, reason is quite > > simple, on my hardware plan9 does do not work (PC emulators couldn't > > help because my program should work with some special hardware), so i > > try to create PC from "supported hardware" list, but it take some > > time to get all pieces, put they together, install, configure plan9 > > and so on )) > > Ok, i have no Plan9, but i have my application that i want to port, > > so i try to remove all autotools macros from it and try to do some > > preparations, like new abstraction layer for threads creation...and > > i'm completely failed, just because too much autotools stuff in > > sources. And it too complicated to figure out what exactly i should > > remove in every case... > > And my application much smaller that mesa for example. Or X11 (by the > > way, how X11 was ported?), and i do not touсh such problems like > > different library, kernel interfaces and so, and so... > > > > So it looks like "project fork" is only way :( > > > > 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: > >> On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > >>> Circular cause and consequence is funny. Let me add to this list: > >>> - jpg > >>> - png > >>> - tiff > >>> - PostScript > >>> - TeX (tpic) > >>> - HTML > >>> - Mahjongg, sokoban, sudoku, tetris (games/4s) > >>> - SPARC, MIPS, x64 > >>> - MP3, PCM, OGG (PAC was made at Bell Labs) > >>> - SoundBlaster 16 > >>> > >>> Let me put it this way: > >>> GNU software is good, except for GNU development tools, > >>> which, > >>> except for the gcc program itself, are mediocre and break > >>> compatibility (try using a Bell Labs makefile with GNU make). > >>> > >> > >> I'd add to it the fact that autotools source files are hard to > >> make, so > >> many people who are to lazy to do it properly just put the famous > >> (in)sanity check and checks for libs they use. The effect? > >> > >> A simple C program that doesn't rely on anything except for > >> example libpng > >> will check for C, C++, FORTRAN 77 compilers, check if those are from > >> GCC and various other things. > >> > >> Imagine my surprise when I had seen a configure script (for EmacsLisp > >> utility) that only checked for Emacs version > >> and few EmacsLisp files it used - a rare thing IMHO, when >80% of > >> configure running time is for checking for not used > >> software. > >> > >> "CPU cycles are cheap, programmer time is expensive" <--- This > >> doesn't > >> mean that total laziness is appropriate. > >> > >> The best thing about autotools is I think the scheme of running > >> configure - AFAIK mplayer doesn't even use configure for it's script, > >> instead > >> they use their own, which looks the same to end user. And saves a lot > >> of time :-) > >> > >> -- > >> Paul Lasek > >> > >
Re: [9fans] A newbie question...
You need to do direct hardware manipulation? Then "project fork" is probably best. On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: Heh, i try to "port" my program, and it's really not possible in my point of view :) Actually, i don't have working Plan9 right now, reason is quite simple, on my hardware plan9 does do not work (PC emulators couldn't help because my program should work with some special hardware), so i try to create PC from "supported hardware" list, but it take some time to get all pieces, put they together, install, configure plan9 and so on )) Ok, i have no Plan9, but i have my application that i want to port, so i try to remove all autotools macros from it and try to do some preparations, like new abstraction layer for threads creation...and i'm completely failed, just because too much autotools stuff in sources. And it too complicated to figure out what exactly i should remove in every case... And my application much smaller that mesa for example. Or X11 (by the way, how X11 was ported?), and i do not touсh such problems like different library, kernel interfaces and so, and so... So it looks like "project fork" is only way :( 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: Circular cause and consequence is funny. Let me add to this list: - jpg - png - tiff - PostScript - TeX (tpic) - HTML - Mahjongg, sokoban, sudoku, tetris (games/4s) - SPARC, MIPS, x64 - MP3, PCM, OGG (PAC was made at Bell Labs) - SoundBlaster 16 Let me put it this way: GNU software is good, except for GNU development tools, which, except for the gcc program itself, are mediocre and break compatibility (try using a Bell Labs makefile with GNU make). I'd add to it the fact that autotools source files are hard to make, so many people who are to lazy to do it properly just put the famous (in)sanity check and checks for libs they use. The effect? A simple C program that doesn't rely on anything except for example libpng will check for C, C++, FORTRAN 77 compilers, check if those are from GCC and various other things. Imagine my surprise when I had seen a configure script (for EmacsLisp utility) that only checked for Emacs version and few EmacsLisp files it used - a rare thing IMHO, when >80% of configure running time is for checking for not used software. "CPU cycles are cheap, programmer time is expensive" <--- This doesn't mean that total laziness is appropriate. The best thing about autotools is I think the scheme of running configure - AFAIK mplayer doesn't even use configure for it's script, instead they use their own, which looks the same to end user. And saves a lot of time :-) -- Paul Lasek
Re: [9fans] A newbie question...
Heh, i try to "port" my program, and it's really not possible in my point of view :) Actually, i don't have working Plan9 right now, reason is quite simple, on my hardware plan9 does do not work (PC emulators couldn't help because my program should work with some special hardware), so i try to create PC from "supported hardware" list, but it take some time to get all pieces, put they together, install, configure plan9 and so on )) Ok, i have no Plan9, but i have my application that i want to port, so i try to remove all autotools macros from it and try to do some preparations, like new abstraction layer for threads creation...and i'm completely failed, just because too much autotools stuff in sources. And it too complicated to figure out what exactly i should remove in every case... And my application much smaller that mesa for example. Or X11 (by the way, how X11 was ported?), and i do not touсh such problems like different library, kernel interfaces and so, and so... So it looks like "project fork" is only way :( 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: > On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > > Circular cause and consequence is funny. Let me add to this list: > > - jpg > > - png > > - tiff > > - PostScript > > - TeX (tpic) > > - HTML > > - Mahjongg, sokoban, sudoku, tetris (games/4s) > > - SPARC, MIPS, x64 > > - MP3, PCM, OGG (PAC was made at Bell Labs) > > - SoundBlaster 16 > > > > Let me put it this way: > > GNU software is good, except for GNU development tools, which, > > except for the gcc program itself, are mediocre and break > > compatibility (try using a Bell Labs makefile with GNU make). > > > > I'd add to it the fact that autotools source files are hard to make, so > many people who are to lazy to do it properly just put the famous > (in)sanity check and checks for libs they use. The effect? > > A simple C program that doesn't rely on anything except for example libpng > will check for C, C++, FORTRAN 77 compilers, check if those are from > GCC and various other things. > > Imagine my surprise when I had seen a configure script (for EmacsLisp > utility) that only checked for Emacs version > and few EmacsLisp files it used - a rare thing IMHO, when >80% of > configure running time is for checking for not used > software. > > "CPU cycles are cheap, programmer time is expensive" <--- This doesn't > mean that total laziness is appropriate. > > The best thing about autotools is I think the scheme of running > configure - AFAIK mplayer doesn't even use configure for it's script, > instead > they use their own, which looks the same to end user. And saves a lot > of time :-) > > -- > Paul Lasek >
Re: [9fans] A newbie question...
That someone had the time and the will to do something like this? On Feb 3, 2008, at 10:01 AM, [EMAIL PROTECTED] wrote: On 3 Feb 2008, at 00:17, Robert William Fuller wrote: An alternative interpretation is that the facts are skewed by the Bell Labs reality distortion field. The syllogism goes something like this: All things not made at Bell Labs are bad GNU is not made at Bell Labs Therefore, GNU is bad Hello children. Today's word is "ad hominem". Can you say "ad hominem"? "We are the knights who say 'NIH'". Not. Nobody's mentioned the antecedents of autoconf&co. other than genealogically. The criticism has been (IMO) well-reasoned. If the appraisals appear somewhat vituperative at times, that is probably because the writers thereof constitute some of the sorry band of unfortunates (myself included) who have been persuaded by circumstance to engage in bootless battle with the autoconf hydra. We eagerly await ingenious and novel counter-arguments explicating the intrinsic intellectual beauty and universal utility of a so-called portability system consisting of 10K+SLOCs of convoluted, inscrutable and non-portable configuration scripts intertwined with a twisty maze of twisted #ifdefs. DaveL
Re: [9fans] A newbie question...
On 3 Feb 2008, at 00:17, Robert William Fuller wrote: An alternative interpretation is that the facts are skewed by the Bell Labs reality distortion field. The syllogism goes something like this: All things not made at Bell Labs are bad GNU is not made at Bell Labs Therefore, GNU is bad Hello children. Today's word is "ad hominem". Can you say "ad hominem"? "We are the knights who say 'NIH'". Not. Nobody's mentioned the antecedents of autoconf&co. other than genealogically. The criticism has been (IMO) well-reasoned. If the appraisals appear somewhat vituperative at times, that is probably because the writers thereof constitute some of the sorry band of unfortunates (myself included) who have been persuaded by circumstance to engage in bootless battle with the autoconf hydra. We eagerly await ingenious and novel counter-arguments explicating the intrinsic intellectual beauty and universal utility of a so-called portability system consisting of 10K+SLOCs of convoluted, inscrutable and non-portable configuration scripts intertwined with a twisty maze of twisted #ifdefs. DaveL
Re: [9fans] A newbie question...
On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Circular cause and consequence is funny. Let me add to this list: > - jpg > - png > - tiff > - PostScript > - TeX (tpic) > - HTML > - Mahjongg, sokoban, sudoku, tetris (games/4s) > - SPARC, MIPS, x64 > - MP3, PCM, OGG (PAC was made at Bell Labs) > - SoundBlaster 16 > > Let me put it this way: > GNU software is good, except for GNU development tools, which, > except for the gcc program itself, are mediocre and break > compatibility (try using a Bell Labs makefile with GNU make). > I'd add to it the fact that autotools source files are hard to make, so many people who are to lazy to do it properly just put the famous (in)sanity check and checks for libs they use. The effect? A simple C program that doesn't rely on anything except for example libpng will check for C, C++, FORTRAN 77 compilers, check if those are from GCC and various other things. Imagine my surprise when I had seen a configure script (for EmacsLisp utility) that only checked for Emacs version and few EmacsLisp files it used - a rare thing IMHO, when >80% of configure running time is for checking for not used software. "CPU cycles are cheap, programmer time is expensive" <--- This doesn't mean that total laziness is appropriate. The best thing about autotools is I think the scheme of running configure - AFAIK mplayer doesn't even use configure for it's script, instead they use their own, which looks the same to end user. And saves a lot of time :-) -- Paul Lasek
Re: [9fans] A newbie question...
No one remembers the Windows development tools! Actually, I have a clear memory of Visual Studio 2005 Express, as I used to develop in C#. That system was one of the (cough - only - cough) good things Microsoft made. On Feb 3, 2008, at 7:49 AM, [EMAIL PROTECTED] wrote: So if i want port some big linux application to Plan9 i need start new project and copy parts of code from original one. From one side it is sad, because it's very ugly development model (for example if original project will be update, i need update my project too, so there are two "targets" for every update). On another hand i could concentrate on new Pla9 techniques and create more powerful analogous of linux software. Eventually, you'd think the autotools will fade, but reality sometimes turns out illogical. I think the "Plan 9 Way" will only become dominant if there is a major change to the present status. Strangely, no one criticises the Windows development tools... ++L
Re: [9fans] A newbie question...
You don't need to do all that if you know what libraries your program depends on. Libraries like pdcurses, libtiff, zlib, etc. have been ported to APE, so once you have them installed, all you need to do is run the configure file and then make from within ape/psh. However, if you need autoconf/automake before a configure file, you're out of luck. On Feb 3, 2008, at 3:44 AM, Filipp Andronov wrote: Hmmm, my question was not about new ideological war "GNU vs Plan9". )) I think that my bad English does not allow me to ask my question in correct form, so i will show some sample :) For example, in Linux i have some big application. This application using autotools, so if a want to port it, for example on different OS (of course if this OS has autotools) or hardware all i need is go throw sources and put something like: #ifdef RUN_IN_CYGWIN // some specific code #endif After that i need to add extra tests in configure and autotools will do all magic for me :) The main trouble is that all sources has really many pieces of #ifdef code, so it could be very painful to drop out "portability in GNU way". But it's ok, until that is a only way. Ok, for me "porting" to plan9 looks like: 1. Drop out autotools from project 2. Replace all OS specific code to Plan9 equivalent 3. Replace all libs to it's equivalent for plan9 4. and so on Main trouble in 1 step. Because after that i couldn't post in project mail list, "Hey gays, i have create Plan9 port of your application, please check it out and put in CVS trunk". If i "port" some application in that way, that mean that I've start new one, "from scratch" and just copy & paste some code from original project :(( I hope that i have logical mistakes in my example, and you show me that, because if not it could be very sad :)) 2008/2/3, Eris Discordia <[EMAIL PROTECTED]>: On Sun, 03 Feb 2008 00:30:38 -, Rob Pike <[EMAIL PROTECTED]> wrote: An alternative interpretation is that the facts are skewed by the Bell Labs reality distortion field. The syllogism goes something like this: All things not made at Bell Labs are bad GNU is not made at Bell Labs Therefore, GNU is bad If you think about what the letters of GNU stand for, you might appreciate that the forms are in mutual opposition. They provide completely different approaches to software. "Good" and "Bad" are value judgments. If you think GNU is the right way to build things, Plan 9 is probably not for you, and vice versa. -rob Is that "the" Rob Pike? "The R?" If so, please accept me humble reverence, sire! Hallowed be thy practice (of programming)! P. S. Down here in my country, Iran, we have this tradition of inventing sacred things out of thin air. A considerable proportion of "the divine and the sacred" spilled all over the globe began with that frailty of ours :-D -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [9fans] A newbie question...
> Strangely, no one criticises the Windows development tools... I do, it's horrible and even more, i just don't know such words on English, to describe all my feelings about windows build system : Perhaps i do not known it very well, but i have some experience of development under windows, and that experience told me do not do such mistake (development under windows) once again :))) 2008/2/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > So if i want port some big linux application to Plan9 i need start new > > project and copy parts of code from original one. From one side it is > > sad, because it's very ugly development model (for example if original > > project will be update, i need update my project too, so there are two > > "targets" for every update). On another hand i could concentrate on > > new Pla9 techniques and create more powerful analogous of linux > > software. > > Eventually, you'd think the autotools will fade, but reality sometimes > turns out illogical. I think the "Plan 9 Way" will only become > dominant if there is a major change to the present status. > > Strangely, no one criticises the Windows development tools... > > ++L > >
Re: [9fans] Plan9 Trademark ?
> The apparent products of Plan9 Software is software consultancy, cheerful > people who give you `thumbs up' sorry, i meant `products ... are'. also i expect they make loadsamoney from their Qualify software whereas we've obviously been reduced to using the cheapest PCs from Walmart. they don't even run Windows!
Re: [9fans] Plan9 Trademark ?
> Plan 9 is an incomplete name. That company refers to themselves as > PLAN9, which is not trademarked. "Plan 9" is a registered trademark in the USA (reg 2065577, `operating system computer programs'). It is registered to Lucent Technologies Inc. That registration is in class 9, which is huge, but the United States puts reasonably tight bounds on the scope of a trademark based on the description of the Goods and Services within that class (unlike, say, the messed-up CTM system). The apparent products of Plan9 Software is software consultancy, cheerful people who give you `thumbs up' and a program called Qualify that is fully buzzword compliant with a suitably dire user interface (to judge from the screen shots). The software isn't called Plan 9, nor is it an operating system, and the set of cheerful people immediately prevents association with the registered trademark.
Re: [9fans] A newbie question...
> So if i want port some big linux application to Plan9 i need start new > project and copy parts of code from original one. From one side it is > sad, because it's very ugly development model (for example if original > project will be update, i need update my project too, so there are two > "targets" for every update). On another hand i could concentrate on > new Pla9 techniques and create more powerful analogous of linux > software. Eventually, you'd think the autotools will fade, but reality sometimes turns out illogical. I think the "Plan 9 Way" will only become dominant if there is a major change to the present status. Strangely, no one criticises the Windows development tools... ++L
Re: [9fans] A newbie question...
Thanks, this is very similar to my thoughts. So if i want port some big linux application to Plan9 i need start new project and copy parts of code from original one. From one side it is sad, because it's very ugly development model (for example if original project will be update, i need update my project too, so there are two "targets" for every update). On another hand i could concentrate on new Pla9 techniques and create more powerful analogous of linux software. thanks for replies ) 2008/2/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > Main trouble in 1 step. Because after that i couldn't post in project > > mail list, "Hey gays, i have create Plan9 port of your application, > > please check it out and put in CVS trunk". > > There's no cure for this. The touted portability of the autotools is > restricted to the GNU environment and the moment you step outside of > it, this is what occurs. It's a philosophy that has turned into a > religion largely by losing its focus or, if you prefer, shifting its > objective. > > Plan 9 becomes the proof thereof, if autotools were as successful as > claimed, it ought to be trivial to port them to a different platform. > It isn't, nor is it necessary. In porting the code for libtiff and > geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools, > png, gd and eventually libtiff and geotiff. The sum total of these > mkfiles is probably less than two thousand lines. But it is > impossible to feed these back to the developers, because they do not > fit into their philosophical scheme. > > As another example, check out graphviz. From version 1 to version 2 > (I think) they moved from a custom configurator to the autotools. > Beside totally losing Plan 9 portability in the bargain, it is my > impression that they spent more effort on the autotools details than > in improving graphviz itself. > > ++L > >
Re: [9fans] A newbie question...
> Main trouble in 1 step. Because after that i couldn't post in project > mail list, "Hey gays, i have create Plan9 port of your application, > please check it out and put in CVS trunk". There's no cure for this. The touted portability of the autotools is restricted to the GNU environment and the moment you step outside of it, this is what occurs. It's a philosophy that has turned into a religion largely by losing its focus or, if you prefer, shifting its objective. Plan 9 becomes the proof thereof, if autotools were as successful as claimed, it ought to be trivial to port them to a different platform. It isn't, nor is it necessary. In porting the code for libtiff and geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools, png, gd and eventually libtiff and geotiff. The sum total of these mkfiles is probably less than two thousand lines. But it is impossible to feed these back to the developers, because they do not fit into their philosophical scheme. As another example, check out graphviz. From version 1 to version 2 (I think) they moved from a custom configurator to the autotools. Beside totally losing Plan 9 portability in the bargain, it is my impression that they spent more effort on the autotools details than in improving graphviz itself. ++L
Re: [9fans] A newbie question...
Hmmm, my question was not about new ideological war "GNU vs Plan9". )) I think that my bad English does not allow me to ask my question in correct form, so i will show some sample :) For example, in Linux i have some big application. This application using autotools, so if a want to port it, for example on different OS (of course if this OS has autotools) or hardware all i need is go throw sources and put something like: #ifdef RUN_IN_CYGWIN // some specific code #endif After that i need to add extra tests in configure and autotools will do all magic for me :) The main trouble is that all sources has really many pieces of #ifdef code, so it could be very painful to drop out "portability in GNU way". But it's ok, until that is a only way. Ok, for me "porting" to plan9 looks like: 1. Drop out autotools from project 2. Replace all OS specific code to Plan9 equivalent 3. Replace all libs to it's equivalent for plan9 4. and so on Main trouble in 1 step. Because after that i couldn't post in project mail list, "Hey gays, i have create Plan9 port of your application, please check it out and put in CVS trunk". If i "port" some application in that way, that mean that I've start new one, "from scratch" and just copy & paste some code from original project :(( I hope that i have logical mistakes in my example, and you show me that, because if not it could be very sad :)) 2008/2/3, Eris Discordia <[EMAIL PROTECTED]>: > On Sun, 03 Feb 2008 00:30:38 -, Rob Pike <[EMAIL PROTECTED]> wrote: > > >> An alternative interpretation is that the facts are skewed by the Bell > >> Labs reality distortion field. The syllogism goes something like this: > >> > >> All things not made at Bell Labs are bad > >> GNU is not made at Bell Labs > >> Therefore, GNU is bad > >> > > > > If you think about what the letters of GNU stand for, you might > > appreciate > > that the forms are in mutual opposition. They provide completely > > different > > approaches to software. "Good" and "Bad" are value judgments. If > > you think GNU is the right way to build things, Plan 9 is probably not > > for you, and vice versa. > > > > -rob > > Is that "the" Rob Pike? "The R?" > > If so, please accept me humble reverence, sire! Hallowed be thy practice > (of programming)! > > P. S. Down here in my country, Iran, we have this tradition of inventing > sacred things out of thin air. A considerable proportion of "the divine > and the sacred" spilled all over the globe began with that frailty of ours > :-D > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >
