Seismic Unix:Community portal

Um... So this page is for discussing What We as a community thinks should be done with the wiki. Feel Free to chime in with you thoughts --Toastar 01:05, 5 October 2011 (MSD)

Contents 1 Installation 2 Help with editing 3 Regression Testing 4 SU help 5 Sandbox 6 Scripts 7 Velocity modeling 8 200314 programs converted to wiki 9 sdoc2wiki

Installation

So I'm thinking I'm going to create 2 pages on the sidebar. The first would be a "How to install". and the Second would be a Developers portal.--Toastar 19:30, 17 October 2011 (MSD)

Help with editing

I've created a very rudimentary Editing Help page so others don't have to endure as much confusion starting out as I did. It needs lots of work since I have very little clue what I'm doing. For example, how does one change the name of a page which already exists? --Rhb 17:19, 29 October 2011 (MSK)

There is an arrow pointing down that is located to the right of "view history" in the upper-right corner. Click it, then "Move". Poliann 17:42, 29 October 2011 (MSK)

Regression Testing

I'm going to need an easy way to transfer to my system the scripts and image files from the Test Library section that will allow me to automate updating the regression test suite. The test cases will consist of a shell script and one or more Postscript images. After I've tested them, I'll be loading them into the mercurial repository that Ricardo created. I'm ultimately expecting to have 4000-5000 scripts and as many or more images. Won't happen soon, but we need to plan for it. I also plan to use the same mechanism to capture bug reports so that they are easier to reproduce and resolve. --Rhb 22:54, 29 October 2011 (MSK)

I guess I'm not sure what the deal is with the Test Library. Just a bit of brain storming here, Perhaps we should encourage uploading .ps files and let the server convert(imagemagick) them on display.--Toastar 01:52, 1 November 2011 (MSK)

If I can retrieve example scripts, data files, and images from the wiki, I can maintain a repository that tracks the output files. I can then automate a way to sit and check for mismatches that need to be investigated. As much as possible I want to use synthetic data for the tests and examples to avoid storage & traffic problems. I'm backing away from Postscript because they can get rather large. So I'm now leaning in the direction of automatically creating png files from Postscript files (e.g. supsimage <data.su | ps2png >data.png ). I'm still handicapped by not knowing much about the mechanics of the web above the IP level, but I'm working on it.--Rhb 22:40, 13 November 2011 (MSK)

SU help

We need to decide on what a typical SU routine help page will look like. They don't have to be identical but they do have very similar structures now and it's probably best to preserve that. Here's an example. We need to decide if we want to add other something else now that we can. When we decide on the structure I can write some simple templates to use throughout. That way if we want to tweak the design later we don't have to edit hundres of pages one by one. Poliann 22:08, 31 October 2011 (MSK)

That looks awesome as far a program definition, I'm thinking flows might be a bit more fluid. IDK but It's something to think about. I think it would be nice if the stuff in flows automatically linked to anything in Category:SU_program. Maybe a bot or something, could do this. --Toastar 01:52, 1 November 2011 (MSK)

Indeed, we need to think through the structure of these flows. Ideally I would like to have at least two types of flows. One is a simple and minimalistic example to illustrate a specific function. Those should be Examples in respective function manuals. The other type is for ones that do something useful. They may require way more lines of code but they still should be readable and instructive. I think any such flow needs a separate page, and they should probably organized by topic. Poliann 00:39, 5 November 2011 (MSK)

I have wikified all help pages linked to from the main list of programs. I now intend to start thinking about creating examples for each function, which will take incomparably longer. Poliann 06:31, 6 November 2011 (MSK)

Sandbox

All experiments should be carried out in the Sandbox to prevent cluttering the space. Poliann 00:45, 1 November 2011 (MSK)

Scripts

What does everyone think about the way scripts are handled now with the source tag? Is there a way to improve on this? Perhaps making them collapsible for large scripts, or maybe easier to download. --Toastar 02:36, 12 November 2011 (MSK)

Reg doesn't like colors. I do. I don't know how that is resolved. As for collapsing or downloading large scripts, I thought about it actually. I think if we could add a button to the upper right corner of every source-environment that downloads the content that would be nice. I have no clue how to do that. We can research this. What I would like to have eventually is all scripts be part of the SU standard distribution. It's not a trivial decision as far as I can tell. Sure, it's convenient for people if they already have all scripts that wiki uses in its examples. But how do we actually ensure that the scripts that can be edited online are always in sync with those in the latest distribution? Maybe, it's too much work and organization. I very much dislike the idea of too much coordination when it comes to wikis. So I don't know. Maybe we should indeed learn how to make source environments collapse and download stuff because I anticipate examples to be fairly large.

While we're on the subject, I think an ideal example is self-contained, it results in an image or terminal output. If it's an image then it should have physical units in the axes, be properly labeled, titled, etc. I do not think that everyone must write their examples like that. But if I edit yours, I hope that you know why. I know that some people may be too busy to play with titles, and I think that is totally fine. It's much easier to polish a working example than writing one anew. I hope that people are fine with it, though. Poliann 07:38, 12 November 2011 (MSK)

It would be good if we could arrange so that we could display a script in several places. There are lots of things that need input data and it would be less work if we could use the data from other examples. I agree that things should be properly labeled, but right now I'd rather have a figure w/o proper labels than no figure.--Rhb 23:55, 12 November 2011 (MSK)

From what I've been reading we need either a parser or tag extension that displays the contents of a file as wikitext. We should be able then to have a Download link next to it. As for my previous comment, transclusion takes care of that.Rhb 00:36, 13 November 2011 (MSK)

This:

https://addons.mozilla.org/en-US/firefox/addon/its-all-text/contribute/roadblock/?src=dp-btn-primary&version=1.6.3

Solves the problem for firefox, though it's a bit screwy to invoke (little button in random spot). There are an assortment of other options mentioned here:

http://en.wikipedia.org/wiki/Wikipedia:Text_editor_support#wikEd

--Rhb 18:50, 13 November 2011 (MSK)

After fooling w/ it a bit, I don't think it will do. I've got books on order and should be able to come up w/ something that will display a script and allow downloading it to a local file.

What I'm really after is to have the examples on the wiki be the regression test suite so that any time we change the software we guarantee that all the examples in fact work. Lots of the stuff in the demos directory doesn't which causes lost of misery for new users and even old ones.--Rhb 20:50, 13 November 2011 (MSK)

It's absolutely the case that no labels is better than no figure. Furthermore, despite seemingly being "more work" it may in fact be easier and faster to have someone who clearly knows what he's doing write a quick script that basically does all the work and then someone else add bells and whistles. Even if all pictures and all need to be replaced that is still faster than one person trying to figure out what other people already know.

It seems to be that the regression test suite may not necessarily be the same thing as demos although a significant overlap is to be expected. I imagine that one can write a script that tests several combinations of parameters and cmp's the result against a reference database that is not very readable and thus unfit to be used for educational purposes. Poliann 21:18, 13 November 2011 (MSK)

Combinatorial testing is, in general, impractical. It's a waste of time unless there's a specific bug that needs to be checked. Look at sucmp. I wrote that specifically for comparing the output .su files. In use, a script runs sucmp against pairs of files and if they don't match, pops them up in windows using suxwigb or suximage for human review. The basic idea is that whenever a new release comes out, all the examples in the wiki should still work the same or else either be updated or the bug fixed if they're not.

As for your comments about labels, etc. I quite agree. At the moment we have examples for less than 2% of the codes. And none of those are very good. But it's a start. The wiki will ultimately contain lots of human judgments. Those are key to a regression test. The examples on the wiki are presumably things a human has looked at and decided are correct. However, I know from experience that we'll find bugs in codes that no one noticed that the output was wrong.--Rhb 22:25, 13 November 2011 (MSK)

Velocity modeling

Of the models that I think are essential, the one I still don't have is dipping layers. I know we can generate them using C/awk but is there perhaps a more straightforward way to do it in SU? Poliann 19:50, 16 November 2011 (MSK)

200314 programs converted to wiki

I just randomly checked the full list of programs. We have exactly 200 at this point. :) I hope we have crossed the equator. Poliann 23:36, 20 November 2011 (MSK)

I think I'm mostly done with the conversion. There are core functions that have not been moved. I think it is less of a priority although we will move them eventually. Poliann 06:16, 14 December 2011 (MSK)

sdoc2wiki

Reg has an routine that helps convert sdocs to wiki. I was thinking that the connection between sdoc and wiki should probably be pretty loose. Clearly we need to explain the parameters and such but the whole point of having the wiki is that we can put way more information. Even the parameter descriptions don't have to be abbreviated and so on. We need to think of a way to make sure the wiki stays current without it being updated automatically. Poliann 08:57, 21 November 2011 (MSK)