logilogi-list Mailing List for LogiLogi - Software Libre for the Web (Page 40)

Logilogi.org:3000 is going down after I try to login from the
homepage. LL is down when myopenid.com returns me to LL after a
successful login.

I couldn't login yet ;)

-- 
Bruno

> > I'm back to work at LogiLogi and happy about this. I'm working on a UI
> > draft to show some ideas to fix what I see as the biggest UI problems
> > to use LL.
>
> Looking forward to seeing them. Also the people from Nijmegen will
> likely be interested as the idea's of both of you might enricht
> eachother. Also they don't have drafts of the UI yet, so your timing
> is good :)
>

I would guess my work will be more simple than theirs, and what I mean
by simple is without being tested or backed up with justification, but
instead I'm trying to group the graphical aids by their roll and guide
as much as possible the users through the use of the tool in a
productive way.

> > I've been also following the mailing although not participating. I'm
> > glad to be back home and able to work again.
>
> How was Europe/Spain ?
>

Europe has been a great experience in a whole. Spain was most of it
work but I had a great time also and learned lots of things too. I
knew the south-east zone of Andalucia and we went to Valencia,
Sevilla, Benalmadena and mostly we stayed at Granada, which is a very
nice city.
After Brussels I also went to Miguel's house at Grenoble, France, and
it was a beautiful place.

I'm planning moving to work to Europe, but I don't know when and it
depends if I get a good job over there.

Later.

-- 
Bruno

> Hello all.
> 
> I've been out of work for some time, since the Fosdem. I has been a
> great experience, mostly meeting Wybo and Bram has been great.

Great to see you back!

> I'm back to work at LogiLogi and happy about this. I'm working on a UI
> draft to show some ideas to fix what I see as the biggest UI problems
> to use LL.

Looking forward to seeing them. Also the people from Nijmegen will
likely be interested as the idea's of both of you might enricht
eachother. Also they don't have drafts of the UI yet, so your timing
is good :)

> I've been also following the mailing although not participating. I'm
> glad to be back home and able to work again.

How was Europe/Spain ?

greetings,

Wybo

> Greetings all,
> 
> later.
> -- 
> Bruno

Hello all.

I've been out of work for some time, since the Fosdem. I has been a
great experience, mostly meeting Wybo and Bram has been great.

I'm back to work at LogiLogi and happy about this. I'm working on a UI
draft to show some ideas to fix what I see as the biggest UI problems
to use LL.

I've been also following the mailing although not participating. I'm
glad to be back home and able to work again.

Greetings all,

later.
-- 
Bruno

At the request of the people from Nijmegen I just created a branch for them in
the Subversion repository.

It can be found here:
https://logilogi.svn.sourceforge.net/svnroot/logilogi/branches/gip

Now and then they will be merged. This branch is mainly for trying things out.
If another branch might be needed for an experiment or something like it, just
ask me or create one yourself (those with commit-rights have commit-rights
everywhere, we do not count on distrustfull restrictions but on good judgement
in how it is used).

For active development it is also adviced that you subscribe to the
commit-mailing-list at: http://lists.sourceforge.net/mailman/listinfo/logilogi-svn
and/or lurk often in the #logilogi irc-channel... so we can do code-review.

greetings,

Wybo

The people from Nijmegen have created a requirements-document. It
clearly describes what Manta is all about, and also their plans are
laid out therein.

Their ideas for the GUI are not yet in here in visual form, but the
other things they will do, are (like a pdf-generator, a WYSIWYG-
editor, and latex mathematical formulas).

It looks like good work!:
http://logilogi.org/pub/manta/requirements.pdf

---

About the Modulizer: We did not move to edge rails, as without doing
this a plugin-system was also possible thanks to the plugins_plus
plugin of PluginAWeek.

greetings,

Wybo

I just committed the MantaModulizer-plugin. In concordance with the
BodyBuilder module and the 3rd party plugins_plus
(http://wiki.pluginaweek.org/Plugins_plus) plugin this enables us to
further develop Manta in almost a perfect aspect-oriented way...!

In the main layout there were included a @left_body, @right_body and
@header_body. These now can be filled also from modules. Like the
geo_user module (/vendor/plugins/geo_user), which now contains the
google-maps user-location logic (not all is extracted yet, but enough
to give you an idea)...

Simply add a method to the left body from a controller like:

left_body :my_new_method

And then it will be appended to the @left_body variable that is shown
in the view.

Models, Controllers, Helpers and Views can be added in a tree simmilar
to the main application-tree, but inside the plugin's lib-dir.

So /vendor/plugins/geo_user/lib/app/models/user.rb contains the model-
data that is automatically added to the main user-class on reload.

I will be adding some more documentation to the modules later this
week...

---

The developer-snapshot has also been fixed for Linux. A dependency was
missing and the ferret-check failed due to a change in Rails. These
are fixed now. For now I won't be testing with windows as I think
there will be too much that might need changing (also in libraries) for 
that...

greetings,

Wybo

The plugin for allowing modules to be developed for Manta is almost
there. While what I have now is already working, I still ran into 
some ugly bugs when testing, so I will first resolve those and then
commit...

Also I got a report from Charl (From Nijmegen) that the snapshot is
not working under windows, and also giving some errors under Linux. I
have been playing around with the Windows-installation this evening, 
and I found the same errors. Tomorrow I will be checking up the Linux-
one in a clean installation. I can't promise that I will make it work 
on Windows soon, but I definitely will fix the linux- version (if I 
can replicate the errors).

Also soon we will have the proposals of the people from Nijmegen for
their additions and upgrades to the Manta system. So stay tuned to the
list if you like to have a say about these...

greetings,

Wybo

It seemed good to me to change the licensing from GPL v3 to
Affero-GPL v1 and any newer version because:
* Licensing under a draft license is not a very secure strategy
  anyway...
* As became apparent today the 3rd version of the GPL will not
  contain point 7b4 any more, thereby effectively stopping to be
  a copyleft license for web-applications. The whole idea of the
  GPL was to allow users the power over the sourcecode of the 
  programs they use, and for most users of web-applications usage 
  is accessing something that runs on someone elses server.
* The Affero-GPL (approved of by the FSF and OSI) does guarantee
  users the right to download the most recent version (running
  sourcecode) of the program they are using online.

By this move we effectively will not change anything in the 
license of Manta, as the Affero-GPL is practically identical to
the GPL + our previous 7b4 condition.

I already committed this change. If one of you really objects,
we can discuss it...

Wybo

-- 

::Student:
- History, Informatiekunde (computer linguistics, IR, webtech) and Philosophy
- Member of the Center for Metahistory Groningen (http://www.rug.nl/let/cmg)

::Free Software and Open Source Developer:
- http://www.LogiLogi.org, Cumulative, shared commenting, publication and 
                           idea sharing: Where insight comes together...
- ComLinToo, a computational linguistics toolset written in Perl
- Lake (LogiLogi.org Make), a make-replacement using makefiles in pure C++

::Being:
- In the world, wavy hair, go figure (http://nl.logilogi.org/HomE/WyboWiersma)

(Below the question is asked in Dutch about whether we should use an
existing WYSIWYG, or whether one should be built from scratch. I sent
this reply to the list, as it might be interesting for others, and/or
for the record).

I have a slight preference for using an existing Open WYSIWYG over
implementing one ourselves. This for reasons of browser-compatibility
and collaboration on the maintenance of the editor. Of course the
chosen editor should be relatively lightweight, extendable, and last 
but not least it should also be possible to take out parts of it's
functionality.

I think it's best to first of all to allow basic textual styles (like
bold, centered, text-(background)-colors, superscript, titles, lists,
indentation) tables, and images and the like.

Another worthwile feature could be allowing people to add links from
images, and/or from parts of them. So one can make diagrams or models
and make parts it them clickable.

But preferably users should not be able to add random divs, javascripts,
or to change background-colors of tables. Also I think we should not
allow direct html-editing.

I haven't seen enough WYSIWYG editors to judge, but TinyMCE (plugins) 
and openWYSIWYG (simplicity) seem interesting.

If we put the WYSIWYG editor (and the link-adder/remover, as added part 
of it) in place, we can just as well drop Textile alltoghether, and 
store straight HTML (of course still without Logi-links inside the
text).

Wybo

> Hallo Wybo,
> 
> We hebben al wel eens eerder gesproken over een
> What-You-See-Is-What-You-Get editor op LogiLogi. Op dit moment zijn
> we even aan het verkennen wat de mogelijkheden hiervoor zijn. De
> belangrijkste keuze die moet worden gemaakt is: maken we gebruik van
> een standaardproduct of bouwen we iets "from scratch". Om hier de
> juiste keuze over te maken is het belangrijk om te weten welke
> functionaliteit deze WYSIWYG editor moet onderstenen. Gaat het
> alleen om basale functionaliteit (bold,cursief,underline,link maken)
> dan is de meest voordehandliggende keuze om het zelf te
> implementeren. Echter, als er meer functionaliteit nodig is dan is
> het misschien verstandiger om van een standaardproduct uit te gaan.
> 
> Zou je misschien kort je visie hierop willen geven?
> 
> Mvg,
> 
> Allan van Hulst
> 
> 

-- 

::Student:
- History, Informatiekunde (computer linguistics, IR, webtech) and Philosophy
- Member of the Center for Metahistory Groningen (http://www.rug.nl/let/cmg)

::Free Software and Open Source Developer:
- http://www.LogiLogi.org, Cumulative, shared commenting, publication and 
                           idea sharing: Where insight comes together...
- ComLinToo, a computational linguistics toolset written in Perl
- Lake (LogiLogi.org Make), a make-replacement using makefiles in pure C++

::Being:
- In the world, wavy hair, go figure (http://nl.logilogi.org/HomE/WyboWiersma)

I improved the rationalization a bit, and I implemented it. Bugs with
Concepts that have no default Word will not happen anymore. This part
of the logic is ok now.

What remains to be added however is in the UI, namely the screen for
the addition and removal of senses (to/from concepts). The matching
controller taking the destroy- requests will have to check if the
sense could be destroyed. If it cannot the user should be presented
with a list of links and tags that are in the way, and imho with the
option of at least choosing to break the links (by removing the
concepts where it does not match with the word anymore, and by adding
new concepts for words for which the sense to be removed was the last
sense) and have them re-resolved where neccesary.

I've added a task for this to the tracker.

The new Word-, Sense-, Concept- deletion-rationale is:

First the external use constraints (not related to either of the other two):

  Concepts:
  * not if they're fulfilling a role (associated with a group, mode, stance...)
  * not if they are used as tags

  Senses:
  * not if it's concept and word appear together in a LinkPart

  Words:
  * not if used in a link-part

Then the relational constraints:

  Concepts:
  * not if it has any sense that cannot be deleted at the external
    level

  Senses:
  * not if it is as_default_word and it's concept cannot be destroyed
    (at any level)

  Words:
  * not if any related sense cannot be destroyed at the relational level.

And at last the destruction-process itself:

  Concepts:
  * destroy all related words that can be destroyed
  * delete all it's senses

  Senses:
  * destroy it's concept and/or word if they can be destroyed

  Words:
  * will never be destroyed directly by the user, so only is
    responsible for destroying itself

greetings,

Wybo

Tasks item #1686401, was opened at 2007-03-22 23:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=898717&aid=1686401&group_id=78643

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wybo Wiersma (wybow)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add a screen for adding and removing senses

Initial Comment:
See the thread on the list.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=898717&aid=1686401&group_id=78643

I made a small list of constraints that have to be kept in mind for
deleting Concepts, Senses and Words. I did this because in bugreport
1685774 I identified a problem with the deletion the mentioned objects.

This rationalization has not been implemented yet.

Deletion:

First the external constraints (not related to either of the other two):

  Concepts:
  * not if they're fulfilling a role (associated with a group, mode, stance...)
  * not if they are used as tags

  Senses:
  * not if it's word and concept are found together in a LinkPart

  Words:
  * not if used in a link-part

Then the relational constraints:

  Concepts:
  * not if any related word figures in a LinkPart and this is the only
    concept for that word

  Senses:
  * not if it is as_default_word and it's concept cannot be deleted at
    the external level

  Words:
  * not if any related sense cannot be destroyed at the external or
    relational level.

And at last the destruction-process itself:

  Concepts:
  * remove it from any LinkParts, and re-resolve those links
  * delete all it's senses

  Senses:
  * destroy it's concept and/or word if they can be destroyed

  Words:
  * destroy all it's senses

greetings,

Wybo

Charl (one of the students from Nijmegen) created a proposal for
changing some things in the data-structure of Manta. It's on-line 
here, for those of us interested:

http://www.logilogi.org/pub/manta/req_diff_en_datastructuren.pdf

Charl is also on this list, so I will ask a few questions about it
here, so he and others might give their views on them.

General remarks:

* First of all: the proposal gives a clear description of the 
  current system, and contains an interesting proposal about 
  which I really would like to know more.
* An issue is though that I'd be interested in seeing some 
  benchmark-data. I suspect that not the saving and diffing of 
  the text, but the resolving of links will take most time in an 
  average-sized logi to which, say 4 new links were added...
* I wonder how much of that would disappear if we implemented the
  diff-algorithm in C++, or if we wait for YARV 
  (http://www.atdot.net/yarv/,
  http://www.antoniocangiano.com/articles/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal)
  Ruby really seems to me to be the wrong language for pointer-
  juggling.

Links:

* A thing that should be taken care of is how the links will be
  resolved after one saves a logi as a new text. The current 
  procedure is to translate the link-positions to absolute space 
  and then look at which links changed, and re-resolve only those.
* For speed-reasons links must be pre-resolved (so we can have
  incoming links, and the link-drop-downs will load within reasonable
  time) what is your plan for this, especially as we don't want
  duplication of incoming links from different versions (I could
  imagine still using positions for links, but then we still will 
  have to apply the diff-algorithm).
* It should still be possible to link to specific versions after
  this change (but this would not be a problem, as we could add a
  version-column to the logi-table)

Tags:

* I really think that tags should be applied to logi's and not to
  versions. Semantically this makes more sense, as logis should be 
  short texts and be normally not editable by other authors they 
  are not expected to change that often and thus to remain fairly 
  stable at least semantically.
* Also it will keep some queries - like those for branches, but
  also link-resolving - faster (unless we would store old logis in 
  a separate table).
* This does not mean that keeping Logis separate from LogiVersions
  would mean that we cannot duplicate the body-text in LogiVersions
  instead of in Logis. That might still be a good idea.

Editing:

* I think that this proposal jumps over the problem of link-tags
  inside the text a bit too quickly. Many people in the humanities
  would not like to see link-tags inside their text. Especially
  link-tags because those really break into the text, contrary
  to '''emphasis''', or = titles =. 
* Having links in the text will even be a bigger problem in manta
  because other will be able to add links to your text even if they 
  cannot edit it, so some texts could become quite crowded with 
  links contrary to the wishes of the author.
* So we would really need a WYSIWYG-editor if links were to remain
  inside the text for all edit-modes.

This might seem a lot of questions and remarks, which is true ;)

But they are mainly aimed at getting the proposal, and the issues 
involved clarified... surely not at keeping status quo, or making
the proposed changes seem impossible...

greetings,

Wybo

For the students in Nijmegen I answered some questions about the ideas
behind logilogi manta. The questsions and answers can be read here:

http://giplogi.crystalrealms.net/wiki/Rationale

greetings,

Wybo Wiersma

What would you people think of a move to Rails Edge ?

The main advantage of this is that we can use the new plugin-system
(http://weblog.rubyonrails.org/2007/3/2/plugin-loading-internals-have-changed-for-the-better)
as a basis for Manta Plugins (a plugin-system for LL Manta).

This in turn will make it much easier to add functionalitiy like the
geo-coder, but also the things that will be added by others of us,
like the people from Nijmegen.

Most likely the new plugin-system will be in rails stable in a few
months, so when we make the 1.0 release we could be back at rails
stable.

So what do you think of it ?

greetings,

Wybo

> Problem serving LogiLogi.org:3000
>
> Wybo are you working on it?

Yes, thanks for the report. Clemens Tolboom (whom I know from the
Perl-mongers-, and Ruby User Group meetings) also reported it this
morning. I fixed it now. It was due to zero missing from the SCORES
array inside the Rating model (and yes, - ..sniff.. -, someone did 
vote the homepage down to zero... ;).

I also was already thinking some time about making available
convenient developer snapshots containing all dependencies in one
single tarball, so people don't need to wade through a sea of 
dependencies to get a copy of Manta running on their desktop, 
and today I did this.

You can always download the newest snapshot here:
http://www.logilogi.org/pub/mantasnapshots/logilogi-trunk.tgz

The only things you need besides this one tarball are ruby and mysql.
And if you really want to have the search-page of Manta to work in
your copy, you will also need the ferret gem, but for a first
installation this is really not a must...

The snapshot contains a normal svn checkout, so with svn update you
can keep it up to date, and you could even commit from it (if you have
commit-rights of course).

For those having normal installations (non-snapshot): I updated the
server, and my own boxes to rails 1.2.3, so if you encounter problems
try updating all gems. Also if you get mysterious errors, or even yaml
errors, remove the index dir, if you've got one, as I did get (and
fix) such errors (by doing this) after updating ferret.

greetings,

Wybo

PS: Miguel, already got ideas about the optimalization of our queries ?

> --
> Miguel Lezama

Wybo are you working on it?

-- 
Miguel Lezama

I changed the copyright-notices in the files to refer to the LogiLogi
Foundation now as the copyright-holder. Also I removed my name from
the model-files I created. Instead of the adding of names to source-
files we will be giving credits to those who contributed to Manta in
the CONTRIBUTORS file in /doc. When Manta goes live we might also show
this list online, in a Logi-page.

greetings,

Wybo

On 3/12/07, Wybo Wiersma <wy...@lo...> wrote:
> Again I sent this to the list, so the people in Nijmegen and others
> can read it too, and be kept updated as we are one team now.
>
Sorry, I meant to send it to the list.

> > >Also I might be creating a simple plugin-framework for Manta this week,
> > >as I have to make a program that finds place-names in texts, and gets
> > >their most likely latitude & longitude in the coming weeks, and I might
> > >just as well turn that into a module for Manta that shows the places
> > >mentioned in a logi on a google-map...
> >
> > Great!
> > It would also be great to have logilogi links applied to this
> > automatic linked-places, as there could be some peer-group relevance.
>
> I think it would be neater to keep these parts separated, I am
> thinking about adding like a tiny globe-image after place-names
> on which one can click to center the map.
>
Ok, there are already some approaches similar to what you describe.

> > >English/a visual sketch/demo. If you have some ideas too then now is
> > >the time to sketch them out and post links to the sketches on the
> > >list for commenting (the students from Nijmegen are also on this list).
> >
> > It's great they are already working on the UI, it is top priority
> > right now. It's also a pity I'm not at home and working is not
> > feasible. I'd also would like to work together with them but that wont
> > be possible right now. I'll just get my ideas down to some drawings
> > (at least paper :) and share them so to show my perspective, although
> > I don't know when I'll get to do this.
>
> I am looking forward to them. Let us know on the list when you have
> them online. I will also post links to the proposals from Nijmegen if
> they don't post them directly to the list that is...
>
> greetings,
>
> Wybo
>
> > Greetings!"
>

Later


-- 
Bruno

Again I sent this to the list, so the people in Nijmegen and others
can read it too, and be kept updated as we are one team now.

> >Also I might be creating a simple plugin-framework for Manta this week,
> >as I have to make a program that finds place-names in texts, and gets
> >their most likely latitude & longitude in the coming weeks, and I might
> >just as well turn that into a module for Manta that shows the places
> >mentioned in a logi on a google-map...
> 
> Great!
> It would also be great to have logilogi links applied to this
> automatic linked-places, as there could be some peer-group relevance.

I think it would be neater to keep these parts separated, I am
thinking about adding like a tiny globe-image after place-names
on which one can click to center the map.

> >English/a visual sketch/demo. If you have some ideas too then now is
> >the time to sketch them out and post links to the sketches on the
> >list for commenting (the students from Nijmegen are also on this list).
>
> It's great they are already working on the UI, it is top priority
> right now. It's also a pity I'm not at home and working is not
> feasible. I'd also would like to work together with them but that wont
> be possible right now. I'll just get my ideas down to some drawings
> (at least paper :) and share them so to show my perspective, although
> I don't know when I'll get to do this.

I am looking forward to them. Let us know on the list when you have
them online. I will also post links to the proposals from Nijmegen if
they don't post them directly to the list that is...

greetings,

Wybo

> Greetings!"

I also sent this to the list.

> > Great that everything is fine. How is Valencia ?
>
> Valencia was very nice, I was there for a night and then I went to
> Sagunto, now I'm in Granada and its beautiful.

The weather is probably much better too... :)

> Also, here is the link of the text I told you I read about actor-network
> 
> http://www.lancs.ac.uk/fss/sociology/papers/law-notes-on-ant.pdf

Thanks.

> I'm anxious to get the computer and start working back again with logilogi.

Great! I have been mainly working on things for my studies the past
week, but I'll fix some bugs in Manta today.

Also I might be creating a simple plugin-framework for Manta this week,
as I have to make a program that finds place-names in texts, and gets
their most likely latitude & longitude in the coming weeks, and I might 
just as well turn that into a module for Manta that shows the places 
mentioned in a logi on a google-map...

The people from Nijmegen are getting started now too. They already did
the usabillity research. One of them; Andrew Wolters, suggested that
they will make a proposal for a quite radical redesign of the UI based
on their findings. This is fine with me, but of course you will also
get a big say in discussing their proposal once it's worked out in
English/a visual sketch/demo. If you have some ideas too then now is
the time to sketch them out and post links to the sketches on the
list for commenting (the students from Nijmegen are also on this list).

greetings,

Wybo Wiersma

> Talking, greetings,
> 
> -- 
> Bruno

deleting the index-files solves the problem!

On 3/3/07, Wybo Wiersma <wy...@lo...> wrote:
>
> This looks like a problem with ferret, the search-engine Manta uses.
> When you installed it, did it report any errors or problems ?
>
> (you can try this by running gem install ferret again)
>
> If not, then you could also try to delete all the index-files (the
> directory index and all its contents), and try to run the redo_dev_db
> again...
>
> Wybo
>
> > after "rake redo_dev_db --trace" i get this error:
> >
> > rake db:fixtures:load_inc_config --trace
> >
> > ** Invoke db:fixtures:load_inc_config (first_time)
> > ** Invoke environment (first_time)
> > ** Execute environment
> > ** Execute db:fixtures:load_inc_config
> > rake aborted!
> > File Not Found Error occured at <except.c>:117 in xpop_context
> > Error occured in index.c:825 - sis_find_segments_file
> >        couldn't find segments file
> >
> > /usr/local/lib/ruby/gems/1.8/gems/ferret-0.11.3
> /lib/ferret/index.rb:683:in
> > `initialize'
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> LogiLogi-list mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logilogi-list
>



-- 
Miguel Lezama

This looks like a problem with ferret, the search-engine Manta uses.
When you installed it, did it report any errors or problems ?

(you can try this by running gem install ferret again)

If not, then you could also try to delete all the index-files (the
directory index and all its contents), and try to run the redo_dev_db
again...

Wybo

> after "rake redo_dev_db --trace" i get this error:
> 
> rake db:fixtures:load_inc_config --trace
> 
> ** Invoke db:fixtures:load_inc_config (first_time)
> ** Invoke environment (first_time)
> ** Execute environment
> ** Execute db:fixtures:load_inc_config
> rake aborted!
> File Not Found Error occured at <except.c>:117 in xpop_context
> Error occured in index.c:825 - sis_find_segments_file
>        couldn't find segments file
> 
> /usr/local/lib/ruby/gems/1.8/gems/ferret-0.11.3/lib/ferret/index.rb:683:in
> `initialize'

after "rake redo_dev_db --trace" i get this error:



rake db:fixtures:load_inc_config --trace

** Invoke db:fixtures:load_inc_config (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:fixtures:load_inc_config
rake aborted!
File Not Found Error occured at <except.c>:117 in xpop_context
Error occured in index.c:825 - sis_find_segments_file
        couldn't find segments file

/usr/local/lib/ruby/gems/1.8/gems/ferret-0.11.3/lib/ferret/index.rb:683:in
`initialize'
/usr/local/lib/ruby/gems/1.8/gems/ferret-0.11.3/lib/ferret/index.rb:683:in
`ensure_writer_open'
/usr/local/lib/ruby/gems/1.8/gems/ferret-0.11.3/lib/ferret/index.rb:268:in
`<<'
/usr/local/lib/ruby/gems/1.8/gems/ferret-0.11.3/lib/ferret/index.rb:8:in
`synchrolock'
....


any suggestion?