genex-dev — GeneX developers

[GeneX-dev] Goodbye PI Role

[<ja...@op...>]

Hey All,

The following is an FYI service announcement...

Following up a conversation Harry and I had about having too many
Roles in the DB, I discovered a wierd permission conflict that was
happening between the USER role and the PI role. Since I wasn't able
to justify the difference between these anyway, I decided to take the
'Occams Razor' approach and just eliminate the unnecessary PI role.

So: you never used it ... you won't miss it.

Along similar lines, I discovered another issue. Short explanation: I
created another role (with the stupid name: ADMIN-INSERT).

Long explanation:

There are two tables: Audit and ChangeLog which were listed as ADMIN
tables - data is publicly visible, but only modifiable by users in the
genex_admin group. The Audit table gets an automatic timestamp
whenever a row is inserted or updated in any table. The ChangeLog
table is available for programs to enter information about what was
modified - so if a program inserts an ArrayDesign into the DB, it
should insert a row into the ChangeLog table detailing what got added
and which tables were affected.

Both these tables need to permit normal users to INSERT rows, but no
modifications should be made except by admins. Hence the new role
allows only that.

Cheers,
jas.

Re: [GeneX-dev] [URGENT]: float => integer conversion for scratch

[Harry M. <hj...@ta...>]

Jason E. Stewart wrote:
> Hey Harry,
> 
> This is the last of the *big* issues outstanding for schema changes on
> the DB. 
> 
> Here is a random list of thoughts questions I have about this. Let me
> know what you think.
> 
> - If I understand correctly there are two reasons for wanting to do
>   this: first, it allows the columns to be indexed, and secondly int
>   comparisons are faster than float comparisons.

yes, and 3rd, ints store as 4 bytes as compared to 8 bytes for floats:

http://www.dbexperts.net/postgresql/datatypes

so for a DB that is going to be storing zillions of numbers, ints make a lot 
more sense, even for I/O

and in fact postgres even support 2 byte ints which we could use, but it might 
freak normal people out.  Does anyone really need more than 16K levels of 
precision in an expression value?  That plus an offset would give us what we 
need for any data set.  But I'll settle for 4 bytes per number.  My neighbor 
Charlie Zender uses this approach (packed ints/floats) to achieve best 
compression and i/o in his netCDF Operator utilities and it's a std technique 
for data compression.


> - Do you have an example query that we can use to test the efficiency?
>   I'd like to at least have a couple of tests to show why we did it.

Index any int column of significant size and then query it in a complex query 
that depends on the rank of the data.

select blah where (expression_level < than some_num) and (expression_level > 
some_num) and [some other condition]

the '[some other condition]' is just meant to make it chew up more cycles 
dependent on the comparison.  I remember that when I was trying this, I got more 
than 100 fold better speed on indexed queries (ints) than on floats).



> - How many columns should we do this for, all float columns? Only a
>   single float column - the primary intensity column? Two float
>   columns - allowing cy3 intensity and cy5 intensity? This will be
>   affected by the answer to the next question.

the more we use ints in the underlying DB, the better the performance
will be all around.  I'd say store everything as ints and make the user
interfaces do the conversions if only to mention that the internal
numbers are ints as (the floating point numbers * 1000).


> - how many columns should be indexed in the scratch table? There are
>   generic columns and the indices will use up a great deal of
>   space. By default I think we should index two columns (one for cy3
>   and one for cy5), and allow the DB maintainers to index more if they
>   need it. If we're only indexing two columns, then perhaps we should
>   only float convert two columns as well.

It depends on what columns get called on for comparisons.  Certainly the most 
refined, most normalized  numbers should get converted and indexed.  I think 
we'll have to watch the queries and modify things as we find out more about how 
people query the data.  I'm not sure that the raw cy3/cy5 numbers will get 
queried all that much - I think that most users will want to query based on 
ratios and normalized expression.
> 
> - I'm not sure about how indexing works with the views - since
>   everything is re-written in terms of a SELECT on the underlying
>   table, scratch, I'm *pretty* sure that the indexing should work
>   fine, but without a test, I can't tell.

This I don't know about - I'll start to look into it, but my hunch is much like 
yours - that a query into a view will first look for an index (or can be told 
that an index exists) and only after failing that will it do a row by row, value 
by value comparison.

> 
> end of thought stream.
> 
> Cheers,
> jas.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> https://lists.sourceforge.net/lists/listinfo/genex-dev
> 

-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta...
             <<plain text preferred>>

Re: [GeneX-dev] problem again on local, matrix

[Harry M. <hj...@ta...>]

Thanks, Jason - works fine now.  And the tabs do work fine as well.  I'll have 
comments back to you on the int-float stuff and other stuff later today.

hjm


Jason E. Stewart wrote:
> Harry J Mangalam <hj...@ta...> writes:
> 
> 
>>In response to your latest bug report (("Fixed major DB bug.."), I
>>tried to refresh the installation on matrix.  I thought that tho
>>this was a major bug, it would be a minor update so I tried to do it
>>on matrix simultaneously with my lappie.  That was stupid.  Both of
>>them failed in parallel at teh same point, so there seems to be a
>>problem...
> 
> 
> Fixed ...
> 
> Sorry Harry, two problems, one with SVN and the other was I didn't
> test the install on genex2 first. You have my promise from now on that
> I would advertise any updates unless I've first tested them on genex2.
> 
> I just tested this on genex2 this morning and discovered that when I
> did an 'svn commit' from the root of genex-server - so that it would
> commit *all* files I modified in one commit - it didn't commit the
> modifications to the DTD/table/table.dtd file ...
> 
> I believe this is because DTD/table is an svn:external it's actual
> location in the SVN repo is Perl/Class-ObjectTemplate-DB/dtd but I
> include it (and the two MAGE dtd's) using the svn:external feature
> that lets you create symlinks to files in other SVN archives.
> 
> But apparently, you have to commit svn:external files manually it
> won't do it automatically.
> 
> Just FYI,
> jas.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> https://lists.sourceforge.net/lists/listinfo/genex-dev
> 

-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta...
             <<plain text preferred>>

Re: [GeneX-dev] problem again on local, matrix

[<ja...@op...>]

Harry J Mangalam <hj...@ta...> writes:

> In response to your latest bug report (("Fixed major DB bug.."), I
> tried to refresh the installation on matrix.  I thought that tho
> this was a major bug, it would be a minor update so I tried to do it
> on matrix simultaneously with my lappie.  That was stupid.  Both of
> them failed in parallel at teh same point, so there seems to be a
> problem...

Fixed ...

Sorry Harry, two problems, one with SVN and the other was I didn't
test the install on genex2 first. You have my promise from now on that
I would advertise any updates unless I've first tested them on genex2.

I just tested this on genex2 this morning and discovered that when I
did an 'svn commit' from the root of genex-server - so that it would
commit *all* files I modified in one commit - it didn't commit the
modifications to the DTD/table/table.dtd file ...

I believe this is because DTD/table is an svn:external it's actual
location in the SVN repo is Perl/Class-ObjectTemplate-DB/dtd but I
include it (and the two MAGE dtd's) using the svn:external feature
that lets you create symlinks to files in other SVN archives.

But apparently, you have to commit svn:external files manually it
won't do it automatically.

Just FYI,
jas.

[GeneX-dev] Some new eye candy

[<ja...@op...>]

Hey All,

After a couple of solid weeks of doing nothing but schema changes and
documentation, I need to spend a few hours having fun. So I
reorganized the Mason applications so that the tabs work. Since this
only involves changes to the Mason apps a simple:

  $ svn up
  $ sudo make install_files

will give you the new interface. Click on the different tabs, and the
nav bar and the default app will change. The default apps for Admin
and Annotate aren't all that useful => suggestions welcome. Also, it
might be nice to put a little more thought than I wanted to spend on
which apps should go under which tab.

As some added eye candy, I included the extra banners that were made
for the project a long time ago.

Enjoy,
jas.

PS. Yes, I tested it on genex2 ...

[GeneX-dev] OntologyEntry

[<ja...@op...>]

Hey All,

One question I have is do we want to modify the Genex controlled vocab
implementation to add some rudimentary support for the MAGE
OntologyEntry class for the beta release.

Our current support for a taxonmy controlled vocab is hampered by lack
of support for this. It works but is a bit clunky.

The Genex ControlledVocab table is meant to be very simple. It can
only support a flat restricted vocabulary list where each term has a
name, a category, and a definition. 

One piece it is missing is an optional DatabaseEntry link - this would
make support for taxonomy much better by including the NCBI taxonmy DB
Entry in our local DB and including a link to it from the CV table. I
think this would require no effort to add support for this - no new
tables, I just need to add the CV table to the list of tables that use
the DatabaseEntryLink table and recompile the Perl API.

The final piece to fully support the MAGE OntologyEntry is to allow
hierarchical entries, entries which are composed of other
entries. Personally, this adds a lot of complexit which I don't fully
understand, and I fought against incorporating it into MAGE. However,
the MGED ontology *requires* this feature, so it was included in
MAGE. So if we are to begin using MO to annotate our data - or more
importantly - if we are to allow Genex users to have access to MO, we
will be *required* to add it.

This change will also require that we turn all CV entries into fkeys
to the OntologyEntry table. Currently, we only use the name of the
term, we don't enforce it as a strict fkey relationship. I think this
will be a good thing to do. It will also allow better indexing on the
fkey values if we want to support some sort of complex query based on
CV values.

If possible I would like to not have any planned schema chages between
the beta release and the full genex-2.0 release. So we have to decide
*now* what level of support we want for OntologyEntry.

Converting to full MAGE support will affect almost nothing in the
current Genex system, since we don't really use CV for much of
anything yet. The biggest change I foresee is needing to modify the
script that creates all the Mason annotation apps, which is likely to
be only one hour of work.

Cheers,
jas.

[GeneX-dev] Schema change status

[<ja...@op...>]

Hey All,

Here's the list of proposed schema changes for the beta release:

1.    Schema Changes (? Means a suggestion that I have a good reason
      for but might be better handled another way, open for debate) 
  a.    Make name convention changes (I think this is done)
  b.    UserSec uses integer PK
  c.    Scratch uses integer PK
  d.    Person, Org and Contact_Type (?)  tables
  e.    Linking table from Biomaterial to ControlledVocabulary
    i.    Move most of current Biomaterial attributes to
          Controlled Vocabulary 
    ii.   Add a ControlledVocabularyType table?
    iii.  Leave attributes of taxon, genotype in Biomaterial (this
          can be debated, but will be the most common query)?  
  f.    Add the DesignElement:CompositeSequence class
  g.    Add TestDBA table?
  h.    Add two tables (if two) for Analysis Tree?

Here is the current status:
a,b,f: completed
d: completed, but not Contact_Type table - Role table already exists
e: i, iii: completed
e: ii: no need. If needed Role table exists for this purpose
g: no need.
h: this is post beta release, perhaps even post genex-2.0 release

Added to this list was:
* Adding ArrayManufacture and ManufactureLIMSBiomaterial for tracking
  array printing information, e.g. microtiter plate ID, and plate row
  and plate column. This info was originally part of AL_Spots table.  

* Removed the Species table => it was converted to a controlled vocab
  to match MAGE and the MGED Ontology

* Updated the table which link to external databases to match MAGE
  model of Database and DatabaseEntry

* Updated and test all table roles

Still incomplete:
c: Harry and I are conversing about how best to accomplish this

Cheers,
jas.

[GeneX-dev] [URGENT]: float => integer conversion for scratch

[<ja...@op...>]

Hey Harry,

This is the last of the *big* issues outstanding for schema changes on
the DB. 

Here is a random list of thoughts questions I have about this. Let me
know what you think.

- If I understand correctly there are two reasons for wanting to do
  this: first, it allows the columns to be indexed, and secondly int
  comparisons are faster than float comparisons.

- Do you have an example query that we can use to test the efficiency?
  I'd like to at least have a couple of tests to show why we did it.

- How many columns should we do this for, all float columns? Only a
  single float column - the primary intensity column? Two float
  columns - allowing cy3 intensity and cy5 intensity? This will be
  affected by the answer to the next question.

- how many columns should be indexed in the scratch table? There are
  generic columns and the indices will use up a great deal of
  space. By default I think we should index two columns (one for cy3
  and one for cy5), and allow the DB maintainers to index more if they
  need it. If we're only indexing two columns, then perhaps we should
  only float convert two columns as well.

- I'm not sure about how indexing works with the views - since
  everything is re-written in terms of a SELECT on the underlying
  table, scratch, I'm *pretty* sure that the indexing should work
  fine, but without a test, I can't tell.

end of thought stream.

Cheers,
jas.

[GeneX-dev] Byebye Species table

[<ja...@op...>]

Hey All,

I forgot to mention that I've converted the Species table into a
controlled vocabullary list, and all tables that had fkeys to Species
now instead have a CV entry. This is in alignment with how MAGE and
the MGED Ontology handle taxonomy information.

This is a fairly minor change, but I thought I'd send an FYI just in
case.

Cheers,
jas.

[GeneX-dev] GenexInstall.pm

[<ja...@op...>]

Hey Harry,

In answer to your question about where this module comes from.

It was created when I moved all the generic bits of the DB
configuration/installation into Class-ObjectTemplate-DB so that the
mechanism could be used for other DB's besides Genex. 

The idea is to keep the Install and Configure (now recon.pl) scripts
generic, and put the custom bits in GenexInstall.pm. The Install and
recon.pl scripts should be auto-generated by the C-O-DB
tools. Whenever a change is needed to Install the change is made to
the script master template, and then regenerated. That way all DB
systems using the C-O-DB core benefit from any bugfixes/features from
other projects.

I haven't done a good job of keeping the changes of the past month
into C-O-DB, so it's a bit out of date. But I hope to do so once the
beta release is done.

Cheers,
jas.

[GeneX-dev] problem again on local, matrix

[Harry J M. <hj...@ta...>]

Hi Jason,

In response to your latest bug report (("Fixed major DB bug.."), I tried to 
refresh the installation on matrix.  I thought that tho this was a major bug, 
it would be a minor update so I tried to do it on matrix simultaneously with 
my lappie.  That was stupid.  Both of them failed in parallel at teh same 
point, so there seems to be a problem...

in the installation section:

Ok, this will take a few minutes, hit [Enter] to proceed.

Perl/scripts/gendb.pl --db genex --dir /home/harry/genex/genex-server --user 
genex --pass yeastecol1 --no_ecoli_sf
Creating DB ...

...

Dropping genex ...
Creating genex ...
Couldn't get role for table: <table abbrev_name="cl" api_name="ChangeLog" 
can_self_reference="false" comment="" inherits_from="none" 
is_abstract="false" is_securable="false" name="GENEX_CHANGELOG" role="" 
type="DATA">
  <column comment="" full_name="Accession Number" name="cl_pk" 
not_null="false" type="serial"/>
  <column comment="" full_name="DB Version" name="version_number" 
not_null="false" type="char128"/>
  <column comment="" full_name="Date of Version Creation" name="version_date" 
not_null="false" type="datetime"/>
  <column comment="The audit entry when this data was last modified, it    
will be null if it is the creation event. We set the    write_sql attribute 
to be false so that Postgres doesn&apos;t put    a constraint on this column. 
It is automatically set by a    trigger. " full_name="Audit" name="audit_fk" 
not_null="true" type="int"/>
  <foreign_key can_cascade="false" can_self_reference="false" 
column_id="audit_fk" fkey_card="ONE_TO_ONE" fkey_type="RAW" 
foreign_table="GENEX_AUDIT" foreign_table_pkey="audit_pk" 
is_ambig_fkey="false" is_link_fkey="false" is_lt_fkey="false" 
write_sql="false"/>
  <column comment="" full_name="Description" name="description" 
not_null="false" type="text"/>
  <primary_key column_id="cl_pk" serial="true"/>
</table> at /usr/local/share/perl/5.8.3/Class/ObjectTemplate/DB/XMLUtils.pm 
line 242.
Died at Perl/scripts/gendb.pl line 111.

This looks like a permission problem of the type that the bug was supposed to 
fix ...?

-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta... 
            <<plain text preferred>>

Re: [GeneX-dev] Fixed major DB bug in r1032

[Harry M. <hj...@ta...>]

Got it  - I'll do the update on matrix.  Jennifer, I assume that you haven't 
loaded data yet?

Harry

Jason E. Stewart wrote:
> Hey Harry,
> 
> I've been working with a genex volunteer here in Bangalore named
> Parvez. After a hassle getting debian installed on his workstation,
> getting Genex up was a snap. However, we immediately discovered a
> bug that only appears in Postgres 7.4. Pg 7.3 doesn't properly
> implement permissions on views, and so it lets users do things that
> don't officially have permission to do. I was just noticing it a few
> days ago. It's fixed in 7.4, though, so when we installed it on
> Parvez's machine we couldn't insert data as Joe Random User all of a
> sudden.
> 
> I've just checked in the fix, so updates need to be made.
> 
> Cheers,
> jas.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> https://lists.sourceforge.net/lists/listinfo/genex-dev
> 

-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta...
             <<plain text preferred>>

[GeneX-dev] Tool for batch creation of users

[<ja...@op...>]

Hey Harry,

Just as a convenience I use the script on genex2 to add some default
users to the DB. 

  /home/jasons/create-gmu-users.pl

It will probably be useful in a modified for on matrix.

Cheers,
jas.

[GeneX-dev] Major Schema omission

[<ja...@op...>]

Hey All,

I just noticed that there are two important MAGE classes that got
ommitted. They link the Features on an Array to any Biomaterial's that
were used in the printing process, and include links to any LIMS
information.

I'll add these tables: ArrayManufacture and
ManufactureLIMSBiomaterials to the DB and commit.

Cheers,
jas.

[GeneX-dev] Fixed major DB bug in r1032

[<ja...@op...>]

Hey Harry,

I've been working with a genex volunteer here in Bangalore named
Parvez. After a hassle getting debian installed on his workstation,
getting Genex up was a snap. However, we immediately discovered a
bug that only appears in Postgres 7.4. Pg 7.3 doesn't properly
implement permissions on views, and so it lets users do things that
don't officially have permission to do. I was just noticing it a few
days ago. It's fixed in 7.4, though, so when we installed it on
Parvez's machine we couldn't insert data as Joe Random User all of a
sudden.

I've just checked in the fix, so updates need to be made.

Cheers,
jas.

[GeneX-dev] [ genex-Bugs-924064 ] UserSec must be Admin table

[SourceForge.net <no...@so...>]

Bugs item #924064, was opened at 2004-03-26 10:46
Message generated for change (Settings changed) made by jason_e_stewart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116453&aid=924064&group_id=16453

Category: DB Schema
Group: Genex-2
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Jason E. Stewart (jason_e_stewart)
Assigned to: Jason E. Stewart (jason_e_stewart)
Summary: UserSec must be Admin table

Initial Comment:
No one should change the data in UserSec except for an
admin

----------------------------------------------------------------------

>Comment By: Jason E. Stewart (jason_e_stewart)
Date: 2004-04-10 10:16

Message:
Logged In: YES 
user_id=85550

done

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116453&aid=924064&group_id=16453

[GeneX-dev] [ genex-Bugs-932847 ] Add ArrayManufacture and ManufactureLIMSBiomaterial to DB

[SourceForge.net <no...@so...>]

Bugs item #932847, was opened at 2004-04-10 10:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116453&aid=932847&group_id=16453

Category: DB Schema
Group: Genex-2
Status: Open
Resolution: None
Priority: 8
Submitted By: Jason E. Stewart (jason_e_stewart)
Assigned to: Jason E. Stewart (jason_e_stewart)
Summary: Add ArrayManufacture and ManufactureLIMSBiomaterial to DB

Initial Comment:
These critical MAGE classes were omitted from the
schema. These are the tables that link Array Features
to specific Biomaterial's during the printing process,
e.g. to plate ID, plate row, plate col, etc. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116453&aid=932847&group_id=16453

[GeneX-dev] [ genex-Bugs-932845 ] Fix permissions on views

[SourceForge.net <no...@so...>]

Bugs item #932845, was opened at 2004-04-10 10:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116453&aid=932845&group_id=16453

Category: DB Schema
Group: Genex-2
Status: Open
Resolution: None
Priority: 9
Submitted By: Jason E. Stewart (jason_e_stewart)
Assigned to: Jason E. Stewart (jason_e_stewart)
Summary: Fix permissions on views

Initial Comment:
There was a bug in Postgres 7.3 that allowed users to
violate the security of a view, but it has been fixed
in 7.4, so suddenly users don't have the proper
priveleges (they never did).

For USER tables, members of genex_user need all
permissions on views.

For PI tables, members of genex_pi need all perms on views.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116453&aid=932845&group_id=16453

[GeneX-dev] Jason's mods to config/install - tasty.

[Harry J M. <hj...@ta...>]

Hi All,

Jason, I like your mods - changed some wording in the comments , but kept the 
code untouched.  I also added a few sentences to the INSTALL doc to describe 
how to copy and mod the GeneX.config file.

Did you change the ClassOT stuff for install regardless?  Looks like it.
and it looks like you wrapped the plpgsql stanza so it doesn't emit errors if 
already installed?

both make configure and make install went smoothly on the machine used to 
install genex previously - I;kk try to clean it out to make it mrproper and 
try it again soon as well.

This install looks like it's getting to beta/RC.  At this point, Durga and 
Hrishi should try it as well and post their experiences.
Jennifer, the matrix installation looks like it can support data loading - let 
me know if you want me standing by or helping out if you're going to try it.

-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta... 
            <<plain text preferred>>

[GeneX-dev] Moved to new config mechanism (r1030)

[<ja...@op...>]

Hey Harry,

I switched my copy to be using your new config mechanism.

Here's the bits I tweaked:

* I moved the GeneX.config template into etc/ - our local tests can
  make a copy in the top level directory, but we need to keep an
  unmodified template checked in to SVN, and I figured the best place
  for it was etc/. When we cut a release we can ensure that there is a
  copy in the toplevel dir of the tarball. But there are problems with
  having a file that is checked into SVN and locally modified in
  place. 

* I removed a bunch of old dead options from recon.pl and
  GeneX.config. I'm about to remove all references to GENEX_EXTRALIBS
  and most of the .in files in the process, but that is low priority.

* I made a bunch of the options in GeneX.config be optional - I
  commented them out and left comments indicating they only needed to
  be set if they were different than the default.

* I removed the extra Config.pm that was being created in the top
  level directory. 

Test it, and let me know if I borked anything.

Cheers,
jas.

[GeneX-dev] genex rev 1021 on matrix installs well.

[Harry J M. <hj...@ta...>]

Woohoo!  Except for a stupid mistake in which I tried to use an old config 
file which resulted in missing params, it went really well and the GeneX web 
interface comes up like a champ.

I did discover a bug(?) which may come up when GeneX is installed for internet 
use (DB host is not 'localhost' but the real hostname, but that should not be 
a problem with matrix.  I'll debug this on my machine.

All you linux users, patch & watch out for attacks, especially at .edu's.  
Stanford an other edus are being attacked - multi-user linux and solaris 
machines.

genex2 and matrix are being updated/upgraded as I type.
-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta... 
            <<plain text preferred>>

Re: [GeneX-dev] Class::ObjectTemplate doesn't install

[<ja...@op...>]

Harry J Mangalam <hj...@ta...> writes:

> The supposedly auto-install of new versions of OT & OTDB don't test versions 
> and install themselves the way they're supposed to.  check_mod_version() in 
> the Install script  doesn't work the way it's supposed to.  I'll plink at 
> this after I test the whole thing after manually installing them.

Hey Harry,

Don't bother. I'm just going to remove the check_mod_version
crap. We'll just run: 

  $ perl Makefile.PL
  $ make clean
  $ perl Makefile.PL
  $ make 
  $ make install

For each module, each time. 

If there isn't a Makefile, 'make clean' will fail, so I run perl
Makefile.PL first just in case. Now that I know how to organize Perl
modules for efficient make usage, this goes by in a heartbeat.

Cheers,
jas.

Re: [GeneX-dev] otherwise, good!!

[<ja...@op...>]

Harry J Mangalam <hj...@ta...> writes:

> other than the aforementioned hiccup with the OT/OT-DB versioning and 
> installations, it went smoothly and installed the DB, altho I found more 
> analysis tools-related cruft I still have to remove.
> 
> BUT GOOD!  we're getting close to a release!!

Good! Glad to hear it went smooth. I'll poke at the GUI's on matrix
and see if things are behaving the way they should.

Now we've hit the point of test, test, and test some more. I think we
should lay out a test plan of some sort to try and cover as much as we
can before schema freeze, and then beta release.

Cheers,
jas.

[GeneX-dev] otherwise, good!!

[Harry J M. <hj...@ta...>]

other than the aforementioned hiccup with the OT/OT-DB versioning and 
installations, it went smoothly and installed the DB, altho I found more 
analysis tools-related cruft I still have to remove.

BUT GOOD!  we're getting close to a release!!

-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta... 
            <<plain text preferred>>

[GeneX-dev] Class::ObjectTemplate doesn't install

[Harry J M. <hj...@ta...>]

The supposedly auto-install of new versions of OT & OTDB don't test versions 
and install themselves the way they're supposed to.  check_mod_version() in 
the Install script  doesn't work the way it's supposed to.  I'll plink at 
this after I test the whole thing after manually installing them.

-- 
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hj...@ta... 
            <<plain text preferred>>