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

On Thu, May 29, 2008 at 6:35 AM, Wybo Wiersma <wy...@lo...> wrote:
>> > Ha Wybo,
>> >
>> > Just to drop a short note:
>> >
>> > The layout of logilogi is really weird on Safari (Mac OS X). My guess is
>> > it's because of the rounded corners javascript thingie. I've attached a
>> > screenshot.
>
> Thanks for the note & great to see you checking out Manta again :)
>
> Still, currently, due to time & other constraints we don't support
> Safari, or for that matter any other browser besides Firefox/
> IceWeasel and IE 7 and 6.
>
> This is just pragmatics:
> http://www.thecounter.com/stats/2008/May/browser.php
>
> When we got it all working in these 3 browsers & most bugs fixed,
> Safari will be the 4th on the list.
>
>> > - Andrew
>>
>> Hi Andrew,
>>
>> It looks bad indeed... Miguel, do you have the same problem on Safari?
>
> Indeed & yes he seems to have had...
>
>> rounded corners... arrgg... :)
>
> & browsers & standards... arrgg... :)
>
> Wybo


All, as I've proposed before, we should abandom rounded corners on
browsers that this would make them not able to even use LL... for
safari we could also use an alternative rounding method, (I think it
supports radious styles). What I mean, is that we could at least
desable rounded corners for safari which would be better than what it
displays today...

-- 
Bruno

> > Ha Wybo,
> >
> > Just to drop a short note:
> >
> > The layout of logilogi is really weird on Safari (Mac OS X). My guess is
> > it's because of the rounded corners javascript thingie. I've attached a
> > screenshot.

Thanks for the note & great to see you checking out Manta again :)

Still, currently, due to time & other constraints we don't support
Safari, or for that matter any other browser besides Firefox/
IceWeasel and IE 7 and 6.

This is just pragmatics:
http://www.thecounter.com/stats/2008/May/browser.php

When we got it all working in these 3 browsers & most bugs fixed,
Safari will be the 4th on the list.

> > - Andrew
> 
> Hi Andrew,
> 
> It looks bad indeed... Miguel, do you have the same problem on Safari?

Indeed & yes he seems to have had...

> rounded corners... arrgg... :)

& browsers & standards... arrgg... :)

Wybo

> -- 
> Bruno

On Wed, May 28, 2008 at 9:13 AM, Andrew Wolters
<an...@cr...> wrote:
> Ha Wybo,
>
> Just to drop a short note:
>
> The layout of logilogi is really weird on Safari (Mac OS X). My guess is
> it's because of the rounded corners javascript thingie. I've attached a
> screenshot.
>
> - Andrew
>
>
Hi Andrew,

It looks bad indeed... Miguel, do you have the same problem on Safari?

rounded corners... arrgg... :)

-- 
Bruno

On Wed, May 28, 2008 at 7:26 AM, Wybo Wiersma <wy...@lo...> wrote:
> And yet more good news; LogiLogi Manta will also be presented at the
> Free Knowledge, Free Technology conference in Barcelona...
>
> http://foundation.logilogi.org/2008/5/28/logilogi-at-free-knowledge-free-technology-conference
>
Congratulations Wybo!

> I also will be adding a short philosophical text to LogiLogi each day
> as of today. Most will be in dutch, not all will be new, but at least
> there will be some seed-texts online...
>
Great you'll be adding texts, but sad I won't be able to understand
them... I most likely start some texts too, maybe in spanish, but will
try to do them in english... I'm also talking to some friends that
would be interesting in discussions over LL... I'll try to get them to
participate.

Later...

-- 
Bruno

Ha Wybo,

Just to drop a short note:

The layout of logilogi is really weird on Safari (Mac OS X). My guess  
is it's because of the rounded corners javascript thingie. I've  
attached a screenshot.

- Andrew

And yet more good news; LogiLogi Manta will also be presented at the
Free Knowledge, Free Technology conference in Barcelona...

http://foundation.logilogi.org/2008/5/28/logilogi-at-free-knowledge-free-technology-conference

It is not far from Mont-de-Marssan, so I will be able to get there
easily... :)

In the coming two and a half weeks I will be working on the
preparation of the four presentations and other required documents
(like a 1500 words paper for the FKFT conference) during the morning
hours (except of course on the days on which I visit the Nijmegen-
people, etcetera). So I will only be doing development only in the
afternoons & some evenings...

I also will be adding a short philosophical text to LogiLogi each day
as of today. Most will be in dutch, not all will be new, but at least
there will be some seed-texts online...

greetings,

Wybo

> > If you find problems in the current solution, please let me know,
> > otherwise you can remove the commented out code.
>
> Sorry, you're right. It works with the current code.

Np. happens.

> I also tried to add a svg remove-cross, but there is a problem with
> WEBrick not sending it with the good mime-type. So I commented out
> the svg section and added it as png.

Also svgs are not well-supported yet in IE's so they only should be
there as the source, so it's easy to change them.

> The fixes you made in showLogiLink were not correct. The reason why
> we store the popover in root is that with link-removal sometimes the
> listing_url changes (when links are removed) and we have to reload
> the content of the baloon. In my last commit I added this again.

Sorry, indeed you are right. Good you changed it back.

In all, Steffen and Feng, great work with this link-removal
user-story!,

Wybo

> > greetings,
> > 
> > Wybo

> First of all; good work on the UI-side of the link-removal. I played
> around a bit with it, and it seems to be working good now! :)
> 
> (& it seems very intuitive!)
> 
> > > commented that out in the menu... About the unit-test; doing the
> > > calculations on the position-ranges should be covered by the
> > > position-ranges lib under libs... So let me know if the old
> > > implementation worked or not...
> > 
> > We looked at the PositionRange class and used some methods for
> > remove_links_from_position_ranges and made the unit test work.
> > 
> > It is not possible to use the substract method of PositionRange. If
> > you substract a link which begin and end position is smaller than
> > another link from that link, you have to get two new position
> > ranges. (e.g. 1..8 - 2...5 must be 1..2 and 5..8)
> 
> This is strange, as I've added quite a lot of tests to the
> PositionRange lib on this, and I've added your case now to line 135 of
> the lib/position_range/tests/position_range_list_test.rb, and it 
> exactly 
> does what you say above here...:
> 
> assert_equal PositionRange::List.from_s('1,2:5,8'),
>    PositionRange::List.from_s('1,8') - 
> PositionRange::List.from_s('2,5')
> Also I have commented out your code in logi.rb and added a test to the
> unit-test logi_test.rb where the middle-part of a link is removed, 
> and 
> it works.
> 
> At first it was not saved, but line 325 seems to be enough to take
> care of that.
> 
> If you find problems in the current solution, please let me know,
> otherwise you can remove the commented out code.
>
Sorry, you're right. It works with the current code.

I also tried to add a svg remove-cross, but there is a problem with WEBrick not sending it with the good mime-type. So I commented out the svg section and added it as png.

The fixes you made in showLogiLink were not correct. The reason why we store the popover in root is that with link-removal sometimes the listing_url changes (when links are removed) and we have to reload the content of the baloon. In my last commit I added this again.

> greetings,
> 
> Wybo
> 
> ---
> 

> So what we could do is:
> -----------------------------
> | top 3 from  | tag cloud
> | peer-group  |
> |             | best
> | 7 newest    | users in peergr
> | logis       |
> |             | new users
>
>
> Bruno do you have any ideas on this ?
>

Well, I would say that you'all already said great ideas. It's now
easier now to think over your ideas and maybe add some...

One thing that comes to my mind after reading your ideas is to do some
contending users mixing, which would show another of the logilogi
dimensions for users, like trying to find users that contend
repeatly...

About tag-clouds, what would the size depend on? times used? will we
show all tags or just content tags?

Also about the tags index, it would be nice to introduce some of this
modular display, also like tagcluds, by peergroups, and also a full
index... in fact, this modular display could be considered for most of
the pages as Wybo also proposed (for peergroups)... we'll just have to
think what's mostly needed...

I'm not adding much to this conversation...

It will be very nice to see this information mixing, certainly a next
step for making LL express itself, I would say :)

Later all.

-- 
Bruno

> We had the following ideas for what should be on the frontpage:
> The main idea behind these features is that it introduces the visitor  
> to interesting logi's he might not have seen before.
> 
> - Today's featured logi
> Shows visitors a part of an interesting logi they might not have  
> visited otherwise. (the wikipedia frontpage has a similar feature)

Sounds really cool, but I think that while we have few hands, we
should go for an automatized approach... What we could do & is
simmilar to this, is show a snippet of the best rated logi from a
different peergroup each week or something like this.

> - Most visited tags

I think a tag-cloud might be easier to do.

> - Highest valued logi's

Like a top-3 from a different peergroup each week ? Or from the
selected peergroup by the user.

> - Newest logi's

That one is good & it can include snippets...

I'd also think that somethin like a list of new users, like 
welcoming! .... would be cool...

> Maybe 4 is a bit much (as that would almost certainly mean a big  
> design change for the frontpage to look more like the wikipedia  
> frontpage), but since the results from the above suggestions are  
> likely to overlap, it would be quite easy to loose one.

& we could leave out some of the menu's for the front-page, or maybe
even all...

So what we could do is:
-----------------------------
| top 3 from  | tag cloud
| peer-group  |
|             | best
| 7 newest    | users in peergr
| logis       |
|             | new users

First we could do this for the general peergroup & general for
the newest logis & the new users. Then when logilogi grows we 
can do the weekly peergroups & show the 7 newest rated logi's
by that peergroup & more like it...

(but we might also do that on the peergroup page, we can 
experiment & must see what pplz like...)

Bruno do you have any ideas on this ?

Wybo

---

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

::Free Software and Open Source Developer:
- Active in the LogiLogi Foundation (http://foundation.logilogi.org)
- http://www.LogiLogi.org, Cumulative, shared commenting, publication and 
                           idea sharing: Where insight comes together...
- http://www.OgOg.org, RSS feed articles rating, a meritocracy...
- ComLinToo, a computational linguistics toolset written in Perl

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

> Hi all,
> 
> It's been some time I don't respond to the list, but I've been reading.

We're all lurkers now and then :)

> == link removal ==
> I saw the commits of the link removal and it certainly works very
> nice, and very intuitive as Wybo said. I'll soon get down with
> crossbrowser (IE) compat of some bits of positioning, but someone else
> with JS skils should fix the error preventing logilogi-popover-links
> to show up.

Indeed. Ok. I will look at it today.

> == history & diff ==
> About the history/diff code, Miguel proposed an in-line aproach to
> version comparison, plus it's dynamic display (like good web2.0 LL is
> :), which I think both are very interesting... I first thought going
> inline for comparison would be a mess and hard to deal with, mostly as
> I don't have many examples of inline diff comparison, but after
> researching a bit, I found that even it's not a common approach, it
> could fit our needs, since we dont want a so technical tool, but more
> a more graphical one...

Indeed, it looks quite good & others are having it too (for example
37 signal's Writeboard).

> I was looking at how it's working now, and I have some suggestions to make.
> 
> === Tags ===
> We should decide whether we will compare the code (including tags) or

With tags you mean links ? Or logi-tags, or html-tags ?

> the text (output). This I would guess was already decided for the
> current alpha version of the diff, and for what I can tell, the choice
> was to compare the output text, which I think is the best approach for
> our needs, so this way we will get the user away from the code in all
> cases, when editing, diffing, adding links, etc.  Right now it's not

Indeed I think it's key to keep these things separated. Links,
separate from the text, and when diffing only diffing the text, etc...
This keeps everything simple, both for the user and for us, and it
saves us from hairy exception-cases....

& if you mean html-tags, it makes sense to include those, as they are
inside the text, and the tinymce editor + the diff-algoritm applied
when storing it, will make sure that tags are always neatly closed...

> working as spected, but I guess this is because of the alpha state of
> the code. For example, changing "Original title" by "New title" right
> now in the diff looks like this:
> 
> <span class="diff_new"><h1>New<span
> class="diff_old"></span></h1><h1>Original<span class="diff_both">
> title</span></h1>
> 
> and a diff of changing "original" by "modified" in the paragraph looks
> like this:
> 
> <p>This is the </p></span><span class="diff_old">original paragraph
> text</span><span class="diff_new">new paragraph text</span>
> 
> This is obviously not working as spected right now, and I know it's
> because it's not finished, but I just wanted to show who I would deal
> with tags.

Good bug-hunt & I see now you mean html-tags...

> We should define which tags we are working with, not many by the way,
> h1, h2, p, ol, ul, li, em, strong, sup, sub. With this tags, we could
> define the following way of diffing. We could diff the plain text
> inside structural tags, like headings, paragraphs and lists (items),
> and we should deal inside this tags with the text styling tags, like
> em, strong, sup, sub. This is the best approach I can imagine, and
> maybe, this is already where we are heading to, I didn't talk with
> Miguel about this. This way, the previous examples would look like
> this:
> 
> <h1><span class="diff_new">New</span><span
> class="diff_old">Original<span class="diff_both"> title</span></h1>
> <p><span class="diff_both">This is the </span><span
> class="diff_old">original</span><span class="diff_new">new</span><span
> class="diff_both"> paragraph text</span></p>
> 
> Also I don't know for which cases is the diff_both tag used for.

Miguel is now going for a Javascript-solution, as JS already has a
beautifull HTML-dom model we can work with to fix the tags...

> === Version selection ===
> For the version selection, I would certainly go the wikipedia style,
> which is very intuitive and functional, and it dont have to deal with
> 3 versions comparison... will we deal with this? do we need it?
> 
> Also note, that if we use (like WP) two columns of radio buttons
> (instead of checkboxes), we avoid multiple selection.

Indeed, I really like it that way. So if possible, do it that way, 
Miguel.

> === Styles ===
> Here are the styles with other colors and I also suggest to add a
> white background when a logi is displayed, for better reading and
> differentiation. I could add this if you all agree.
> 
> #overbox div.overpanel#logi_view {
> 	background-color:#FFFFFF;
> 	padding: 8px;
> }
> 
> /*
> Diff colors
> */
> 
> .diff_new {
> 	background-color: #AAFFAA;
> }
> .diff_old {
> 	background-color: #FFD2D2;
> 	text-decoration: line-through;
> }
> .diff_both {  }

I think it's fine yes, although the foreground color of the removed
text could be greyish, and then just wite background-color.

> I think the in-line diff approach will look really nifty!

Indeed :) !

Wybo

> Greetings y'all.
> 
> -- 
> Bruno

PS: While adding a text yesterday I still found some usabillity issues
like the spam-filter being a bit too strict & giving false positives.
Also I added a button for adding h2's inside logi's, for those cases
where you need sub-headers...

Hi all,

It's been some time I don't respond to the list, but I've been reading.

== link removal ==
I saw the commits of the link removal and it certainly works very
nice, and very intuitive as Wybo said. I'll soon get down with
crossbrowser (IE) compat of some bits of positioning, but someone else
with JS skils should fix the error preventing logilogi-popover-links
to show up.

== history & diff ==
About the history/diff code, Miguel proposed an in-line aproach to
version comparison, plus it's dynamic display (like good web2.0 LL is
:), which I think both are very interesting... I first thought going
inline for comparison would be a mess and hard to deal with, mostly as
I don't have many examples of inline diff comparison, but after
researching a bit, I found that even it's not a common approach, it
could fit our needs, since we dont want a so technical tool, but more
a more graphical one...

I was looking at how it's working now, and I have some suggestions to make.

=== Tags ===
We should decide whether we will compare the code (including tags) or
the text (output). This I would guess was already decided for the
current alpha version of the diff, and for what I can tell, the choice
was to compare the output text, which I think is the best approach for
our needs, so this way we will get the user away from the code in all
cases, when editing, diffing, adding links, etc.  Right now it's not
working as spected, but I guess this is because of the alpha state of
the code. For example, changing "Original title" by "New title" right
now in the diff looks like this:

<span class="diff_new"><h1>New<span
class="diff_old"></span></h1><h1>Original<span class="diff_both">
title</span></h1>

and a diff of changing "original" by "modified" in the paragraph looks
like this:

<p>This is the </p></span><span class="diff_old">original paragraph
text</span><span class="diff_new">new paragraph text</span>

This is obviously not working as spected right now, and I know it's
because it's not finished, but I just wanted to show who I would deal
with tags.

We should define which tags we are working with, not many by the way,
h1, h2, p, ol, ul, li, em, strong, sup, sub. With this tags, we could
define the following way of diffing. We could diff the plain text
inside structural tags, like headings, paragraphs and lists (items),
and we should deal inside this tags with the text styling tags, like
em, strong, sup, sub. This is the best approach I can imagine, and
maybe, this is already where we are heading to, I didn't talk with
Miguel about this. This way, the previous examples would look like
this:

<h1><span class="diff_new">New</span><span
class="diff_old">Original<span class="diff_both"> title</span></h1>
<p><span class="diff_both">This is the </span><span
class="diff_old">original</span><span class="diff_new">new</span><span
class="diff_both"> paragraph text</span></p>

Also I don't know for which cases is the diff_both tag used for.

=== Version selection ===
For the version selection, I would certainly go the wikipedia style,
which is very intuitive and functional, and it dont have to deal with
3 versions comparison... will we deal with this? do we need it?

Also note, that if we use (like WP) two columns of radio buttons
(instead of checkboxes), we avoid multiple selection.

=== Styles ===
Here are the styles with other colors and I also suggest to add a
white background when a logi is displayed, for better reading and
differentiation. I could add this if you all agree.

#overbox div.overpanel#logi_view {
	background-color:#FFFFFF;
	padding: 8px;
}

/*
Diff colors
*/

.diff_new {
	background-color: #AAFFAA;
}
.diff_old {
	background-color: #FFD2D2;
	text-decoration: line-through;
}
.diff_both {  }


I think the in-line diff approach will look really nifty!

Greetings y'all.

-- 
Bruno

> This week I also worked with the PositionRanges to get done this task:
> U: A history (diff of versions) screen.

Cool to see code coming in :)

> I take me some time to get used to the PositionRanges but finally I
> think I get them.
> I didn't finished the work but I am getting closer.
> Wybo, I am going to commit the changes but it's not the final
> solution, and I didn't do the update of some files for some days. so
> they will be some conflicts.

I will have a look at possible conflicts tomorrow.

> The idea is to select two versions and get the merge between them with
> a distinguishing color for the text that it's only in one version and
> another color for the text that is in both versions.

Sounds good in principle. Maybe something with green text for added,
and striked-through for removed would be a good idea.

Also we could do something with showing them side-by-side as discussed
in the chat (but as I think about it more the single view might be
good too & definitely be easier to implement & when using spans for
setting the style it might look good too).

So if the side-by-side view is not it in your view, or you'd like to
go for a single view with markings for added/removed, that's ok & we
go your way :)

> I know it's really alpha but I want to know If you all like the approach.

Yes I like it.

> Bon weekend,

I am at my mother's place now & we had some kind of family-meeting.
Also my eee pc 900 arrived friday I & had quite some installing &
configging to do before Manta ran on it & everything worked fine...

(but now it does :) so I will be able to give a live demo at the
conferences, even without inet & still be able to stick this small
machine in my backpack easily...)

I will see if I can squash some more bugs tomorrow & write my first
philosophical text on LL Manta too tomorrow...

greetings,

Wybo

> Miguel

This week I also worked with the PositionRanges to get done this task:
U: A history (diff of versions) screen.

I take me some time to get used to the PositionRanges but finally I
think I get them.
I didn't finished the work but I am getting closer.
Wybo, I am going to commit the changes but it's not the final
solution, and I didn't do the update of some files for some days. so
they will be some conflicts.

The idea is to select two versions and get the merge between them with
a distinguishing color for the text that it's only in one version and
another color for the text that is in both versions.

I know it's really alpha but I want to know If you all like the approach.

Bon weekend,

Miguel

First of all; good work on the UI-side of the link-removal. I played
around a bit with it, and it seems to be working good now! :)

(& it seems very intuitive!)

> > commented that out in the menu... About the unit-test; doing the
> > calculations on the position-ranges should be covered by the
> > position-ranges lib under libs... So let me know if the old
> > implementation worked or not...
> 
> We looked at the PositionRange class and used some methods for
> remove_links_from_position_ranges and made the unit test work.
> 
> It is not possible to use the substract method of PositionRange. If
> you substract a link which begin and end position is smaller than
> another link from that link, you have to get two new position
> ranges. (e.g. 1..8 - 2...5 must be 1..2 and 5..8)

This is strange, as I've added quite a lot of tests to the
PositionRange lib on this, and I've added your case now to line 135 of
the lib/position_range/tests/position_range_list_test.rb, and it exactly 
does what you say above here...:

assert_equal PositionRange::List.from_s('1,2:5,8'),
    PositionRange::List.from_s('1,8') - PositionRange::List.from_s('2,5')

Also I have commented out your code in logi.rb and added a test to the
unit-test logi_test.rb where the middle-part of a link is removed, and 
it works.

At first it was not saved, but line 325 seems to be enough to take
care of that.

If you find problems in the current solution, please let me know,
otherwise you can remove the commented out code.

greetings,

Wybo

---

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

::Free Software and Open Source Developer:
- Active in the LogiLogi Foundation (http://foundation.logilogi.org)
- http://www.LogiLogi.org, Cumulative, shared commenting, publication and 
                           idea sharing: Where insight comes together...
- http://www.OgOg.org, RSS feed articles rating, a meritocracy...
- ComLinToo, a computational linguistics toolset written in Perl

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

> @ Feng & Steffen
> The cloud-positions for the link-removing are still not what they
> should be in Firefox, and also a link-removal unit-test was broken,
> & besides it just was not finished yet, so I also temporarily
> commented that out in the menu... About the unit-test; doing the
> calculations on the position-ranges should be covered by the
> position-ranges lib under libs... So let me know if the old
> implementation worked or not...

We looked at the PositionRange class and used some methods for remove_links_from_position_ranges and made the unit test work.

It is not possible to use the substract method of PositionRange. If you substract a link which begin and end position is smaller than another link from that link, you have to get two new position ranges. (e.g. 1..8 - 2...5 must be 1..2 and 5..8)

The old code just  substracts the begin and you have only one new position range.

We had the following ideas for what should be on the frontpage:
The main idea behind these features is that it introduces the visitor  
to interesting logi's he might not have seen before.

- Today's featured logi
Shows visitors a part of an interesting logi they might not have  
visited otherwise. (the wikipedia frontpage has a similar feature)

- Most visited tags
- Highest valued logi's
- Newest logi's

Maybe 4 is a bit much (as that would almost certainly mean a big  
design change for the frontpage to look more like the wikipedia  
frontpage), but since the results from the above suggestions are  
likely to overlap, it would be quite easy to loose one.

I just updated the public beta with the newest code.

This mainly means that things look different now in IE7. There are
still some small issues, but that's why we call it a public beta :)

I also did a code-review of all commits.

@ Roel & Rens: 
Of the settings-editing still parts are missing, so I temporarily
commented it out in the menu. For implementing the editing of
languages, look at how it was done with the permissions...

@ Feng & Steffen
The cloud-positions for the link-removing are still not what they
should be in Firefox, and also a link-removal unit-test was broken,
& besides it just was not finished yet, so I also temporarily
commented that out in the menu... About the unit-test; doing the
calculations on the position-ranges should be covered by the
position-ranges lib under libs... So let me know if the old
implementation worked or not...

@ Bart & Thierry:
I cleaned up the preferences-js a bit by putting it in a function.

In all a reasonably good day of development! :)

Wybo

PS: I'm looking forward to the proposals for what should be on the
frontpage...

Also I added a blog-post about the server-outage:
http://foundation.logilogi.org/2008/5/20/server-been-down-now-up-again

I just committed the rounded-corners script.

It also works for tags, and for the tabs. I did change the tags from
spans to divs however, to make it standards-compliant & work more
reliable.

There's still some very minor issues with IE7 left, but those seem
to require only tweaks, to fix...

See the Gip pplz tomorrow in Nijmegen,

Wybo

I just saw you claimed the spam-filter task, but I completed that task
already last week. See the posts on the (thorny form) spam-filter of
last week...

(the Thorny Form name was inspired by the thorny bushes with which I
had close encounters many times during my work in my mother's garden
some 8 days ago when I was thinking about how to tackle this
problem... :)

So I closed the task for now, unless you have some additional ideas
about it...

Wybo

I just got an e-mail that the commission-meeting of tomorrow has been
postponed due to the candidate being ill. So I will after all be in
Nijmegen tomorrow!

greetings,

Wybo

I put the server back this morning and everything is working again
now! :)

It was a broken harddisk, which I replaced with another one. Still it
doesn't feel that right that within 5 months 3 harddisks died in this
server, so that's why I'm thinking about a new dedicated one...

I will not be able to be in Nijmegen tomorrow, as tomorrow afternoon I
have to be at the uni in Groningen as part of a commission to hear the 
talk of the first of three candidates for a position at our uni (& later 
decide between them).

But I will be there next week instead.

Today I will round up the rounded corners fix, and make sure it works
without RMagick as long as one does not change the layout or have too
much/long data in the boxes...

greetings,

Wybo

> > Luckily enough everything is well-backed up. And I
> > have the server now at home to see if I can fix
it.

I just fixed the server. It was another broken
harddisk (luckily not both this time). I will put the
server back in the data-center tomorrow...

(& in the meantime I will be looking for a new server,
probably a dedicated server of which the hardware is
maintained by the provider... (this do it yourself
server-hardware-maintenance is in principle fun to do,
but it takes a lot of time, and will be hard when I'm
not in Groningen anymore)... also a bit faster server
would do Manta good... :).

> Ouch...
> 
> if you think a mirror could help, Miguel and I could
> offer to host LogiLogi, although we don't know how
much load our server could handle. If you want to try
it, just let us know.

Hopefully everything is going back online tomorrow...

Also see you on irc tomorrow Miguel :),

Wybo

> Later, and good luck!
> 
> -- 
> Bruno


      

On Sun, May 18, 2008 at 12:49 PM, Wybo Wiersma <wyb...@ya...> wrote:
> When I came home this afternoon I discovered the
> server was down. Really sucks. I went to the
> data-center and tried to boot it up, but it failed
> before booting into the shell.
>
> Luckily enough everything is well-backed up. And I
> have the server now at home to see if I can fix it.
>
Ouch...

if you think a mirror could help, Miguel and I could offer to host
LogiLogi, although we don't know how much load our server could
handle. If you want to try it, just let us know.

Later, and good luck!

-- 
Bruno

When I came home this afternoon I discovered the
server was down. Really sucks. I went to the
data-center and tried to boot it up, but it failed
before booting into the shell.

Luckily enough everything is well-backed up. And I
have the server now at home to see if I can fix it.

More info later or tomorrow...

Wybo

> > PS: Miguel, was it not the case that now, or very
> soon, you are
> > fulltime on LogiLogi as your internship-project ?
>
> Indded, I have my two last exams tomorrow, sorry I
> was not able this
> week. I will take this weekend off to rest and I'll
> see you all monday
> for my first day at fulltime on LL =)