Hey Karl,

.dll is Windows-only. However, compiling libarchive from source is pretty
> smooth, I had no problems doing so on my Linux machine. For the precompiled
> executable we just link statically, so we don't have to worry about this.


The thing is, libarchive needs to be compiled with zlib in order to support
.tar.gz files. While it's not *that* difficult, it's still extra work that
could be easily avoided by shipping two additional files ( libarchive
.dll[for Windows] and .so[for Linux] ). So, wouldn't it be better to ship
those extra files and save everyone from manually compiling libarchive?


That should be okay. How do you retrieve the home directory?


Using Qt's QDir::homePath().
http://qt-project.org/doc/qt-4.8/qdir.html#homePath


 "Error: Failed to open 'MatrixMarket/gearbox.tar.gz'Error: INTERNAL ERROR:
> Function 'archive_read_next_header' invoked with archive structure in state
> 'new', should be in state 'header/data'Detected files in archive:"


Ah, I forgot to remove the libarchive testing. It's attempting to extract a
file that doesn't exist. I should probably implement something to prevent
crashing when doing just that. The interesting here is that it if your
libarchive wasn't compile with zlib, it would still crash even if you had
the file.


 Unfortunately I cannot comment on the GUI with this, as it never pops up.


I haven't done much with the GUI. Been focused on MatrixMarket and file
extraction. I only added system info boxes on the homescreen.


 2 MB is nothing ;-)
> I opt for just integrating it into the executable. One source less of an
> error.


Roger that. Integrating it into the executable.


If a user wants to look around in the MatrixMarket, (s)he can still open up
> the webbrowser. For our purposes it's enough if there's a list of matrices
> with some basic information. So, do we need the grouping?


Perhaps I could re-route opening of external links to be forwarded to the
system's default web-browser. Links used to navigate the MatrixMarket would
use our static pages, while any external links would be opened in the
system's web-browser. How does that sound?

As for the grouping: well we don't really *need* it, but it would be a nice
thing to have...


 If we have a static list of matrices (which can be generated automatically
> from the HTML), we can do all kinds of searching ourselves, can't we? ;-)


 I guess so.



- each matrix entry can be examined to show full details about it. Among
>
> these details there are links to other web sites. Obviously, we can't
>
>   provide static pages for 2700 entries.
>
> I think we can safely mirror these without any problems.


 I don't quite follow you on this one. Are you thinking we could collect
all the detailed info for each of the 2700 matrices?
The details I was referring to are the ones you see when you click on a
matrix. For example:
http://www.cise.ufl.edu/research/sparse/matrices/AG-Monien/3elt.html

As you can see, there are lots of data about it that isn't shown in the
matrix list. I assume this data is important, and should be viewable from
within our MatrixMarket. My concern was that these detailed pages contain
links to external sites, enabling users to go outside our static html
pages.


Different thought:

Instead of all these complicated HTML transformations, isn't it simpler to
> extract the most relevant informations for each matrix and populate an
> internal (stripped-down) list with that? One you have this basic data set
> up, you can do everything with it: Regenerate the HTML page, use widgets to
> display a list, searching, etc. At the same time, it will be much faster
> than any JavaScript modifications. What am I missing?


I think this is where all problems come from. It all basically comes down
to this:
-is it enough to provide only the most relevant info for each matrix (like
the info shown when listing matrices:
Group/Nameiddownload# rows# colsnonzerostypesymspd?-or, do we need to
provide ALL matrix info, including the detailed info shown when examining
individual matrices?

If we just need the basic stuff, then all is fine. I'll make a static list
containing the basic info of each matrix, and use it to generate our static
MatrixMarket pages.
Providing detailed info, however, is not that easy since there's a lot of
it.

So which one is it?

Regards, Namik
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel

Reply via email to