openSUSE Programming August 2006

programming@lists.opensuse.org

13 participants
15 discussions

problem with ps2pdf13
by MAURA MONVILLE 30 Aug '06

30 Aug '06

Thank you for offering to help. I uploaded the same image in both EPS and PDF format. The EPS was produced on a Sun system (wally). There are 2 PDF files respectively generated on the same Sun system and on a Linux/Red-Hat nodes cluster (heimdall). The files can be accessed at the following URL: http://www.trusoftdev.za.net/maura I'd like to summarize the history of such files. The EPS file has been created by a Tcl/Tk program through saving to the disk the canvas image. The Tk code that generates the EPS file can be found in the Tk generic dir in the Tk source distribution TkCanvasPs.c or something like it (see: http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/generic/tkCanvPs.c?... and http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/generic/prolog.ps?v... ) The PDF files were generated on both systems by ps2pdf13. I also uploaded two TXT files , "Heimdall-Info.txt" and "Wally-Info.txt", containing all the info that I could find about the two platform (wally and heimdall) on which "ps3pdf13" produces different results. Thank you in advance, Maura Edelweiss M.

2 1

problem with ps2pdf13
by MAURA MONVILLE 29 Aug '06

29 Aug '06

I have the following image format translation problem. I wonder if someone can advice me about a possible solution. A Tcl/Tk code builds an image on the canvas (Tcl/Tk jagon) and is saved to an eps file by the Tcl "canvas --> postscript" command. While the eps (this format is Tcl-imposed) file looks fine, the pdf version, obtained through the Linux "ps2pdf13" platform-independent conversion, has all the histogram_bar marks and labels messed up. I build the histogram_bar marks and labels by using a font family "adobe-courier' declared in the Tcl program in order to be able at run-time to dynamically change its size according to the user's selections. The histogram_bar marks, that get screwed up by ps2pdf conversion, consist of powers of 10 whose exponent can be either positive or negative ( for instance 10 to the power12 or 10 to the power -11). The base (10) is displayed through a bigger font with respect to the exponent. The font size pair (respectively for the base and the exponent) is selected depending on the GUI window size (Extra-Large, Large, Medium, Small). Since the canvas picture can have two radiobutton-selectable aspect-ratios, namely 1:1 and 16:9, all fonts are "rescaled " (size changed accordingly) back and forth when the aspect ratio is changed. Is the abobe Thank you in advance for your help, Maura

2 2

Bug in parted command .
by MASTHAN DUDEKULA 25 Aug '06

25 Aug '06

Hi All, Here an intresting issue on parted command. I have a device of size 1074 MB and i tried to create partitions with parted command. The intresting issue is, the start position of first partition is not constant. The following snippet explain you more on this. lx88245:~ # parted -s /dev/sdc print Disk geometry for /dev/sdc: 0kB - 1074MB Disk label type: msdos Number Start End Size Type File system Flags lx88245:~ # parted -s /dev/sdc mklabel msdos lx88245:~ # parted -s /dev/sdc mkpart p 0 1065 lx88245:~ # parted -s /dev/sdc print Disk geometry for /dev/sdc: 0kB - 1074MB Disk label type: msdos Number Start End Size Type File system Flags 1 1kB 1065MB 1065MB primary type=83 lx88245:~ # parted -s /dev/sdc rm 1 lx88245:~ # parted -s /dev/sdc print Disk geometry for /dev/sdc: 0kB - 1074MB Disk label type: msdos Number Start End Size Type File system Flags lx88245:~ # parted -s /dev/sdc mklabel msdos lx88245:~ # parted -s /dev/sdc mkpart p 0 1069 lx88245:~ # parted -s /dev/sdc print Disk geometry for /dev/sdc: 0kB - 1074MB Disk label type: msdos Number Start End Size Type File system Flags 1 32kB 1069MB 1069MB primary ext3 type=83 lx88245:~ # parted -s /dev/sdc rm 1 lx88245:~ # parted -s /dev/sdc mklabel msdos lx88245:~ # parted -s /dev/sdc mkpart p 0 1071 lx88245:~ # parted -s /dev/sdc print Disk geometry for /dev/sdc: 0kB - 1074MB Disk label type: msdos Number Start End Size Type File system Flags 1 1kB 1071MB 1071MB primary type=83 lx88245:~ # In the first ( parted -s /dev/sdc mkpart p 0 1065) and third ( parted -s /dev/sdc mkpart p 0 1071) case the start position of first partition is 1 KB ( first block ) but in second case ( parted -s /dev/sdc mkpart p 0 1069) it is ( 32 kB). Can anyone explain it why it is happening like this ? is it bug in parted command ? Your help is appreciated ? Regards Masthan

2 2

Re: Ihre Bewerbung
by Danny Kukawka 24 Aug '06

24 Aug '06

On Thursday 24 August 2006 21:08, Benjamin Sonnemann wrote: > Guten Tag, > > natürlich habe ich noch Interesse. Meine Zeugnis Kopien müssten heute > zwischen 16:45 und 17:15 bei ihnen eingegangen sein, agesendet von der > Firma FarbTex, da ichselber kein Fax besitze. Telefonisch bin ich > eigentlich immer zu erreichen, da müssen sie einen schlechten Moment > erwischt haben. Meine Mobilnummner für solche Fälle ist: > 01729402893 > Nach 22:00 stelle ich allerdings meine Telefone ab. > > Mit freundlichen Grüßen > Benjamin Sonnemann Sorry, aber nachdem das nun ja nicht die erste mail diesen Monat ist und so langsam wirklich nervt: Bist du zu dä**** deinen Mailclient zu bedienen oder zuminstest vor dem Senden den Empfänger der Mail zu prüfen? Danny

1 0

Is qla2xxx driver supports SLES 10 ?
by MASTHAN DUDEKULA 17 Aug '06

17 Aug '06

Hi , At the time of booting , SUSE 10 (ia64 m/c) chowing that, qla2xxx driver is not supportd by novell , tainted flag is enabled ( Not exactly this , iam saying in my own words ). Is qla2xxx driver supports SLES 10 ? Thanks in advance Regards Masthan

2 1

Re: Re: [suse-programming-e] converting a timestamp
by ken_jennings＠bellsouth.net 16 Aug '06

16 Aug '06

> From: Per Jessen > peter burden wrote: > > Per Jessen wrote: > >> I should explain what I'm really doing here: > >> I sscanf() the timestamp into a 'tm' struct, and I correct the year and > >> month such that they comply with what 'tm' expects. Then I convert to > >> a number of seconds since the epoch using mktime() and subtracting the > >> number of seconds as specified in the offset part of the timestamp - > >> e.g. +0200 becomes -7200 seconds. > >> But my number of seconds always ends up being off by 3600 seconds, i.e. > >> 3600 seconds less than it should be. > > I wonder if this is something to do with daylight saving times settings. > > Your +0200 log file offset may be composed of +1 hour for your > > Central European time zone and +1 hour for local daylight saving > > time. > > Yep, that is correct. > > > If, when you "hand crafted" the struct tm maybe you didn't set the > > tm_idst field, mktime() would apply a further 1 hour correction since > > daylight saving time is in force locally - see tzset(3). > > True, I haven't set isdst - problem is, I would much prefer not having > to find out if we've DST or not ... Yeah, DST is a bear. I gather you're trying to generate epoch time from a timestamp that is already recorded in a log. If the DST state is not recorded in the log as part of the time stamp and the system observes DST then you' are going to have to determine it yourself . And that's for the timestamp time, not for the "current" system time, so you have to figure out if it WAS DST in the past not if it IS DST now. If you can change the system to use UTC or to record UTC in the log that might help simplify the problem.

2 1

Re: [suse-programming-e] converting a timestamp
by Per Jessen 16 Aug '06

16 Aug '06

peter burden wrote: > Per Jessen wrote: >> I should explain what I'm really doing here: >> I sscanf() the timestamp into a 'tm' struct, and I correct the year and >> month such that they comply with what 'tm' expects. Then I convert to >> a number of seconds since the epoch using mktime() and subtracting the >> number of seconds as specified in the offset part of the timestamp - >> e.g. +0200 becomes -7200 seconds. >> But my number of seconds always ends up being off by 3600 seconds, i.e. >> 3600 seconds less than it should be. >> > > I wonder if this is something to do with daylight saving times settings. > Your +0200 log file offset may be composed of +1 hour for your > Central European time zone and +1 hour for local daylight saving > time. Yep, that is correct. > If, when you "hand crafted" the struct tm maybe you didn't set the > tm_idst field, mktime() would apply a further 1 hour correction since > daylight saving time is in force locally - see tzset(3). True, I haven't set isdst - problem is, I would much prefer not having to find out if we've DST or not ... /Per Jessen, Zurich >> >> /Per Jessen, Zürich >> >> >> > >

1 0

converting a timestamp
by Per Jessen 16 Aug '06

16 Aug '06

I'm post-processing loglines from a log written by syslog-ng - maybe not the best of interfaces, but the log is the best record of the activity I'm checking for. The loglines have a timestamp like this: 2006-08-15T20:33:57+0200 I need to convert that to a number of seconds since 1970-01-01 00:00:00 UTC. I looked at strptime, but that doesn't take the GMT-offset into account, so I decided to sscanf() the timestamp into a 'tm' structure. Then I use mktime to turn into a number seconds. The question is - mktime() looks at the local timezone settings ... which I'd rather it didn't. OK, I could fiddle with the TZ variable and make it UTC, but as I'm multi-threaded this could have undesired effects elsewhere. AFAICT, syslog-ng does not have an option for also logging the timestamp as the number of seconds since the epoch, which would obviously otherwise have been the best option. I might still look into patching syslog-ng. Any other suggestions? /Per Jessen, Zürich

1 1

Determining where a file really is
by Roger Oberholtzer 15 Aug '06

15 Aug '06

I have a data collection system that collects data to hot swappable disks. Is there a way I can determine the type of media a file will be written to? Let me explain: I have a diskless boot system. The Linux OS and all come from over the network. So, unless I mount a disk, anything written anywhere will be to RAM. If I mount a disk, the file will be written to the disk and not RAM. How can I determine that it is a disk and not RAM? The disks are mounted via udev. The mount point exists as a directory whether there is a disk mounted over it or not, so I cannot use that to see. I want to know if there is a disk mounted where I am writing, or somewhere above it. As I read this question I too think it sounds odd. But I really would like to know. Maybe statvfs()? If the size of the media is greater than some test limit, (RAM in the machine perhaps) then it must be some mounted thing? Is there a better way? -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23

4 8

Keyboard events
by Roger Oberholtzer 15 Aug '06

15 Aug '06

(If this is too non-suse-specific for this list, just shout. But the platform it will run on is SUSE 10.x) Back in the days of character displays (non-X at least), if I wanted quick key press notification I simply set up the keyboard file descriptor to send SIGIO when a user pressed a key. Worked a charm. Then came X... I still need quick key press notification. However, multiple window GUIs make this very difficult. The key press is tied to a window and must be processed in the proper context. I buy that. But what if I need the fastest and most reliable (in terms of latency) access to a key press in a program running under X? The reason for this is that I have an application where a user indicates an activity by a key press. Delays are to be avoided. I have been toying with using some USB key device (e.g., www.xkeys.com) instead of the keyboard. But isn't there a delay in USB 1 transmissions? Perhaps this is less than the delay in X. in getting the key to me. Any ideas? Maybe I can get key presses more direct from X and pass back the ones I am not interested in? There is a caveat: I do X via embedded Tk. The scripting capability is really handy. But the Tk library has access to X. -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

openSUSE Programming August 2006