Older blog entries for huge (starting at number 15)

sh : je te plains si tu n'as que ça à faire de lurker ici pour poster un message juste quand je reviens ici ... :-)

So, it's the week-end here in France.

This is very cool because I just solved my bug on my HTML/CSV/Excel library on IIS/ASP at work. The aim of this library is to output 2-dimensions data in HTML file (table), CSV file or Excel file (with the Spreadsheet::WriteExcel library). You feed in the formats of the columns (name of the column, size, data type for Excel pretty formatting, etc) and the data and automagically you got the file with the right format. This is useful when you have a listing to display to the user on a Website and want her/him to be able to download it in CSV and/or Excel. You just have to build the format, write the subroutine which will output the data and plug it in the library, and voila.

The library is able to write the data to a file. It can also send the file to the user on a website with Content-Disposition: attachment; filename= ... It can handle CGI (with "print" statement to output the header and then the content) or Win32::ASP (with $Response -> AddHeader ).

Here was the bug:

Everything was working fine on CGI/Apache/Linux. CSV and HTML were OK for ASP/IIS/Windows. But it was not working for Excel files on ASP. No error message, just an empty file. I guess it was a binary/text problem because CSV/HTML worked and a quick test show me that local file writing on the server worked.

Here is the solution:

I began to search on the Perl Script Introduction and see this useful code snippet on BinaryWrite. Not bad but this is useful when you had your data in a scalar. Unfortunaly, Spreadsheet::WriteExcel just write to files or "-" to output on STDOUT. The "new" method help had some useful information on CGI interfacing or mod_perl but nothing on ASP. But the answer was in "filehandle.pl", in the example 4. In this example, you can map a scalar to a file handle.

So, if I can get the output of Spreadsheet::WriteExcel in a string, turn binary mode on and output it to the browser, I'm in. Should work, in theory.

First step:

Install IO::Scalar:

install IO-Stringy
Code :
use IO::Scalar;
use Win32::OLE::Variant;
$Response -> {ContentType} = 'application/vnd.ms-excel';
$Response -> AddHeader ('Content-Disposition', "attachment; filename=\"$filename\"");
(Hint : don't use "$Response -> AddHeader ('Content-Type')" because it will add the header, not overload the "text/html" Content-Type)


tie *XLS, 'IO::Scalar', \$xls_str;
$workbook  = Spreadsheet::WriteExcel -> new (\*XLS);
my $variant = Win32::OLE::Variant->new( VT_UI1, $xls_str);
So now, weeeeeeeeeeeek-end ...


I just remembered my password.

Yes, 3 years after my last post ...

Weird ...

10 Jan 2001 (updated 1 Feb 2006 at 18:05 UTC) »

This little toys are, humm, cute. I need one.

9 Jan 2001 (updated 9 Jan 2001 at 15:03 UTC) »

Well. Back to work after some holidays. Will speak about it another day. I wrote this diary entry mostly for mathieu : Tu as jusqu'à 3 mois avant la fin de ton report pour demander un report pour CDI, donc jusqu'en maî 2001.

A propos, si quelqu'un à un truc pour changer de CDI et garder son report ...

Work : I am working on a Rich Media generation tool, an admin (a gfx co-worker who has clue) will produce some templates (SMIL and HTML -- in fact XHTML) and some keys/values stuff with the keys in the templates, and the luser will have a dynamic HTML form to fill. This will be a simple app for the moment, all the keys will be replaced by their value, and whereas the SMIL and XHTML are XML-based, I will not use DOM facilities, only the text struture.

In fact, I will do a very incremental process, because :

  1. with a prototype and lots of releases, management will see that I am "working".
  2. I setup a CVS and will use it.
  3. I looked at XP and there seems to be good things in it, for example incremental process.

Too bad, I have no time to put a Junit test framework in place, so I will go live for this time.

I wrote the specs for the app yesterday, today I will do some HTML form workflow and UML diags of the app.

21 Dec 2000 (updated 1 Feb 2006 at 18:05 UTC) »

Ok. (Yes, real-time diary :p)

"La Défense" isn't cool. You can't open windows in these fscking buildings, and the offices are way too warm (I'm in T-shirt.).

And hey ... all the J2EE stuff are way too cool to build and to work with, all the classes, API and docs, but the deployement is a night-mare. I need to update my TODO list : find a solution, guy, trick ... cause I DON'T want to make deployement of my code. And I don't have time to. Need to speak about this to my boss ...

21 Dec 2000 (updated 1 Feb 2006 at 18:07 UTC) »


A long time since I wrote an entry.

It's 02:25 PM here, just have a good lunch and drink with coworkers. I'm following a training for the week at "La Défense" in Paris. This is a sort of "place" with lots of buildings, and the weird thing is that there is people who are *living* here. It is not that bad to work, you come at 09:00 AM and you leave at 07:00 PM and voilà.

Yesterday, I bought a funny little white hat for my best friend, she'll be so cute with that :)

The training stuff is about java/JSP/Servlet/JavaBean/EJB ... (sorry you Sun people, I forgot the "TM" stuff) and it is not that bad to have a training, books are good to learn but sometimes training makes things go faster and easier to understand.

Weather is so hot in Paris for a December, there is no snow :( (unlike all the people on their diary : "Hey, we've got 40cm here", I hate you men :pp)

In fact I'm very tired.

Ok, not a lot of things to say and I have a bunch of people to certify.

26 Sep 2000 (updated 1 Feb 2006 at 18:09 UTC) »

My NetApp report isn't finished. Will try to finish it this afternoon.

My tests are almost finished, I will polish the report tomorrow, and I need to make the conclusions. There is a few things to know to use efficiently the filer, so I will add it. And I will have the opportunity to see some people from NetApp in Paris, they've got a demo lab.

20 Sep 2000 (updated 20 Sep 2000 at 12:53 UTC) »

Ok, just a little update :

  1. the URL of the report is now http://xenon.medisite.net:8080/huge/report.html
  2. one guy from the VAR which sells us our servers came this morning and helped me tuning the NetApp. It seems that there is a few tricks to know.
  3. our switch *have* the trunking feature, which is cool :-) I just need to activate that on the switch and to configure the Quad Ethernet NIC on the filer.
20 Sep 2000 (updated 20 Sep 2000 at 12:55 UTC) »

Ok, one thing I remembered after posting my entry yesterday :

- In fact I was running *2* bonnie on the filer, the first on /vol/vol1 and the other on /vol/vol2, so the 2900 K/sec on per char / Sequential Output is just wrong. Quickly, I think I had to double that number. In fact, just forgot these

Here is the method I will use :

My test host (xenon) will be on a 10/100 switch (DLINK 3216) with the filer (using the built-in NIC). There is also 5 or 6 servers on the switch but I don't think it will interact. I will mount the filer /vol/vol1 with NFS (v2) and do a bonnie -2000 (not -1000 cause the filer is a 512 MB one). This first test will test the HD stuff and the network stuff of the filer, but I think the bottleneck is the network between my host and the filer. Yesterday I got 3/5 MB / sec traffic, it seems that bonnie generate a lot of traffic, maybe it is the data to be written in the file. I will look at the source later.

To test only the HD stuff, I think I will create a 10/20 GB file on one volume and mv it onto the other. I hope there will be the least possible networking stuff involved in this second test to stress the HD.

I also updated the report to add a SCSI 2 HD I have at home and a IDE HD.

And it seems that my lwm screenshot was a lot more popular than the bonnie report :

9:56 [huge:pts/2] xenon ~% grep screenshot.png /var/log/apache/access.log | wc -l
9:56 [huge:pts/2] xenon ~% grep report /var/log/apache/access.log | wc -l

6 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!