Hey,
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.
>
> Well, it should not crash, but report an error message ;-)
Well yeah, it should. And I thought libarchive would do that for me. But it
seems they don't that kind of checking, so I'll have to add a small
procedure to check for non-existing files before trying to extract them.
Sounds good. I just don't know how tricky it is to redirect the URL to an
> external webbrowser.
It shouldn't be too tricky. I'll override QWebView's URL request handling
to filter out external links and use QDesktopServices::openUrl to launch
URLs in an external webbrowser. Should work fine.
> What I was trying to say is that if we don't trust in stable URLs for the
> matrix market, we can mirror everything below
> http://www.cise.ufl.edu/research/sparse/matrices/
> somewhere within our own webspace if needed.
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?
>
> Basic :-)
Ah I see. That's all clear now. Since we are providing only the basic
matrix info in our MatrixMarket, then there's no need for mirroring. It
might be a good idea to save a backup of all the matrix files and their
images ( 160GB ), in case something happens with Florida's URLs. But then
again, they have their backup hosted on Amazon AWS so it's not a big issue
at the moment.
I think this is shifting our focus too much from providing a benchmark GUI
> to providing a MatrixMarket GUI. There's enough other work left to be done,
> so let's not waste the rest of GSoC on the MatrixMarket browser. One can
> always provide a better, more detailed view later if users ask for it.
Agreed. Implementing the basic info version of the matrix list.
Karl, thanks for clearing things up.
Regards, Namik
On Tue, Jul 22, 2014 at 11:49 AM, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
> Hi,
>
>
> > .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?
>>
>
> Well, then one has to provide 32 and 64-bit versions of both, but still it
> may not work on other systems due to separate paths. Those who compile the
> GUI themselves are developers, so it is perfectly reasonable to expect a
> clean compilation procedure here. That's what build-systems are for.
>
>
>
> 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
>>
>
> Good, thanks!
>
>
>
> "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.
>>
>
> Well, it should not crash, but report an error message ;-)
>
>
>
>
> 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.
>>
>
> OK.
>
>
>
> 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?
>>
>
> Sounds good. I just don't know how tricky it is to redirect the URL to an
> external webbrowser.
>
>
>
> 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
>>
>
> What I was trying to say is that if we don't trust in stable URLs for the
> matrix market, we can mirror everything below
> http://www.cise.ufl.edu/research/sparse/matrices/
> somewhere within our own webspace if needed.
>
>
>
> 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.
>>
>
> I think this is shifting our focus too much from providing a benchmark GUI
> to providing a MatrixMarket GUI. There's enough other work left to be done,
> so let's not waste the rest of GSoC on the MatrixMarket browser. One can
> always provide a better, more detailed view later if users ask for it.
>
>
>
>
> 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/Name id download # rows # cols nonzeros
>> type sym spd?
>>
>
> For me it certainly is enough.
>
>
>
> -or, do we need to provide ALL matrix info, including the detailed info
>> shown when examining individual matrices?
>>
>
> Certainly not now.
>
>
>
> 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?
>>
>
> Basic :-)
>
> Best regards,
> Karli
>
>
>
------------------------------------------------------------------------------
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
