Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes

2009-01-19 Thread zehetner 
Hi,

thought first it's a MW 1.11 vs 1.13 issue but I'm using now MediaWiki 1.13.3
(r45906) where I just switch between the 'old XSDValue' SMW and the 'latest
DBkey' SMW version. Nothing else changes so I thought it might be relatet to the
new version. It's not really a problem for me as I can use mTextform instead but
I was just surprised to find that difference. 

if ($object->getTypeID() == '_wpg')
  
   $pft = $object->getTitle()->mPrefixedText;

If I print_r $object->getTitle() I get:

Old SMW: Semantic MediaWiki (Version 1.5a-SVN) (is 1.4 I think but shows in
Special:Version as 1.5a)

Title Object
(
[mTextform] => Entomological inoculation rates
[mUrlform] => Entomological_inoculation_rates
[mDbkeyform] => Entomological_inoculation_rates
[mUserCaseDBKey] => 
[mNamespace] => 0
[mInterwiki] => 
[mFragment] => 
[mArticleID] => -1
[mLatestID] => 
[mRestrictions] => Array
(
)

[mCascadeRestriction] => 
[mRestrictionsExpiry] => 
[mHasCascadingRestrictions] => 
[mCascadeRestrictionSources] => 
[mRestrictionsLoaded] => 
[mPrefixedText] => Entomological inoculation rates
[mDefaultNamespace] => 0
[mWatched] => 
[mLength] => -1
[mRedirect] => 
[mOldRestrictions] => 
)


New SMW: Semantic MediaWiki (Version 1.5c-SVN)
Title Object
(
[mTextform] => Entomological inoculation rates
[mUrlform] => Entomological_inoculation_rates
[mDbkeyform] => Entomological_inoculation_rates
[mUserCaseDBKey] => 
[mNamespace] => 0
[mInterwiki] => 
[mFragment] => 
[mArticleID] => -1
[mLatestID] => 
[mRestrictions] => Array
(
)

[mCascadeRestriction] => 
[mRestrictionsExpiry] => 
[mHasCascadingRestrictions] => 
[mCascadeRestrictionSources] => 
[mRestrictionsLoaded] => 
[mPrefixedText] => 
[mDefaultNamespace] => 0
[mWatched] => 
[mLength] => -1
[mRedirect] => 
[mOldRestrictions] => 
)

Cheers,
Gu

Quoting Markus Krötzsch :

> On Montag, 19. Januar 2009, zehet...@molgen.mpg.de wrote:
> > Hi,
> >
> > it seems that the field 'mPrefixedText' in a Title object is now empty
> with
> > the new SVN version while previously it contained a value. Is this
> > intentionally?
> 
> I don't quite understand. The class Title is part of MediaWiki and SMW is not
> 
> changing it at all. To access the prefixed text of some title, use 
> getPrefixedText(). This should work in all version of MediaWiki. In any case,
> 
> SMW is not responsible if it fails, I hope ;-)
> 
> Cheers,
> 
> Markus
> 
> >
> > Thanks,
> > Gu
> >
> > Quoting Markus Krötzsch :
> > > Update:
> > >
> > > I have tested the current SVN version successfully in combination with
> > > SemanticForms and SemanticResultFormats, and we now run it on a number
> of
> > > SMW
> > >
> > > sites. We might have an intermediate release with this update soon --
> > > those who cannot wait may wish to give the current SVN version a try (it
> > > can be installed on top of SMW 1.4.* by simply replacing the files).
> > >
> > > Upgrade is strongly recommended for everybody who experiences "blank
> > > pages" (typical for PHP out-of-memory issues) on certain SMW-related
> > > operations. The
> > >
> > > changes can also speed up page display significantly under certain
> > > circumstances, especially if inline queries with many results and
> > > printouts are used.
> > >
> > > Cheers,
> > >
> > > Markus
> > >
> > > On Freitag, 16. Januar 2009, Markus Krötzsch wrote:
> > > > Hi all,
> > > >
> > > > I have done some debugging of SMW's memory requirements during parsing
> > > > and query answering, and I identified a number of issues that lead to
> > >
> > > increased
> > >
> > > > memory usage. To fix this, I have modified some parts of the internal
> > > > architecture, which I will check into SVN soon.
> > > >
> > > > In effect, SMW (SVN) is faster and requires less memory, but I also
> > > > assume that the changed architecture may still have some bugs. Also,
> > > > there might theoretically be minor incompatibilities with SMW
> > > > extensions, though I do not expect many such issues since the old
> > > > interfaces have been kept unchanged. Yet, SVN users are hereby warned
> > > > that some problems might still appear in places. Of course, feedback
> is
> > > > welcome.
> > > >
> > > > There will be another mail to the developers' list with details.
> > > >
> > > > Cheers,
> > > >
> > > > Markus
> > >
> > > --
> > > Markus Krötzsch
> > > Semantic MediaWikihttp://semantic-mediawiki.org
> > > http://korrekt.orgmar...@semantic-mediawiki.org
> 
> 
> -- 
> Markus Krötzsch
> Semantic MediaWikihttp://semantic-mediawiki.org
> http://korrekt.orgmar...@semantic-mediawiki.org
> 
> 





--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.

[SMW-devel] SMW_SpecialAsk.php line 352

2009-01-19 Thread Brendan Crosser-McGay 
Using the latest copy, I'm having problems performing a special ask, it
looks as though the getResultHTML function doesn't exist anymore (was a 1.2
function) and has been replaced with a do-it-all function getResult.  So the
result needs to be changed to

$result = $printer->getResult($res, $params, SMW_OUTPUT_WIKI);  (or whatever
the output should be, in this case I just thought it appropriate to use
SMW_OUTPUT_WIKI  :)
Hope that helps,
-Brendan
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes

2009-01-19 Thread Joel Natividad 
Hi Markus,

Just out of curiosity, what version of PHP did you use while profiling?

Going by Special:Version on semantic-mediawiki.org, it says
PHP5.2.0-8+etch13.  Is that the version you used?

Looking at the PHP Changelog (http://www.php.net/ChangeLog-5.php), 5.2.0 was
released Nov 2006, and there have been several changes to PCRE (from v6.7 to
7.8  - http://www.pcre.org/changelog.txt ), memleaks plugged and perf tweaks
since then.

I realize you're running Debian-etch-stable and Debian has a very
conservative upgrade regimen.  But now that you're focusing on squeezing as
much performance from SMW, it may be worthwhile to see how the underlying
PHP version may be influencing performance.

Perhaps, you can then identify the "best" or recommended PHP for us SMW
users.  And maybe (cross fingers) the upgraded PCRE in PHP may address some
of the regexp problems you discussed in the past.

Thanks,
Joel
-- 
===
j...@natividads.com * wirel...@natividads.com
Think Different! (http://en.wikipedia.org/wiki/Think_different#Text)
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Re: [SMW-devel] Making #set a true semantic call

2009-01-19 Thread Yaron Koren 
Well, all of this makes sense. Just to confirm, it's not planned to ever
have #declare or #set produce a display, other than error messages?
I ask about all of this because I'm thinking of having Semantic Forms
support #set and/or #declare, both in parsing templates and in creating
them.

-Yaron


On Mon, Jan 19, 2009 at 1:35 PM, Markus Krötzsch <
mar...@semantic-mediawiki.org> wrote:

> On Dienstag, 13. Januar 2009, Yaron Koren wrote:
> > On Mon, Jan 12, 2009 at 5:25 AM, Markus Krötzsch <
> >
> > mar...@semantic-mediawiki.org> wrote:
> > >  I do not want to contribute to the general
> > > interface discussion here,
> >
> > Well, I'd like to hear your opinion on the issue, if possible - yours is
> > obviously the most relevant one.
>
> I don't really think so. I must say that I don't care much about syntax.
> But
> since you are asking I can explain some technical considerations that I
> have
> when thinking about new input methods:
>
> * Parsing [[ ]] is not easy and requires us to look through the wiki-text
> string for matching patterns. This causes some issues since the PHP library
> we
> use crashes on large matches. This is why nested annotations and links were
> disabled. In contrast, parsing {{ }} is done by MediaWiki for us, and
> nesting
> annotations is not a (technical) problem there.
>
> * Parsing [[ ]] is not clean since it happens at a stage during parsing
> where
> MediaWiki has half-processed the input. This makes the whole thing somewhat
> messy and undefined. Parsing {{ }} is clearly preferred there, since {{ }}
> have a clear place in the DOM of MediaWiki.
>
> * Parsing annotations requires database lookups, e.g. to get the type of
> some
> property. Technically, it would be desirable to collect many database calls
> into one (or at least into few). This might be easier with inputs like #set
> or
> true semantic templates where many inputs are collected within one parser
> function. Annotations spread all over the page would require multiple runs
> to
> first gather, then jointly parse, and finally output all annotations.
>
> In addition, I think that it is nice if users can see the output SMW gives
> after processing some annotation value (as opposed to #set). For example,
> this
> could include tooltips, hyperlinks, or warning messages. Some datatypes
> such
> as Code also provide more complex formating for data, which is rather
> useful
> to have.
>
> Summing up those four points, and adding my further experience that most
> SMW
> sites will want to use SemanticForms, I arrive at the following conclusion:
>
>
>  SMW's primary input mechanism should be an extended form of the current
> semantic templates (#declare). Annotations would be declared (this works
> already) on template pages, so that some parameters get annotated
> automatically without the need of [[ ]] syntax in the template code. Pages
> then simply use the template, provide parameters as usual, and some of the
> latter are turned into annotations and displayed accordingly (this is what
> does not work yet; #declare does not display any SMW output, not even
> errors).
>
>
> To do this, someone needs to extend #declare (and the associated
> processing)
> so that annotated parameters are replaced by the texts that SMW returns
> when
> processing the values (including error messages and the like). Like the
> current [[ ]] thing, this approach is still universal in the sense that
> every
> wiki could be modified to use only those "semantic templates" and still
> would
> look and work exactly the same way. Yet, no more [[ ]] parsing would be
> needed
> (of course we would keep this as an optional input for backwards
> compatibility).
>
> -- Markus
>
> P.S. I also think that a syntax with {{ }} is more likely to be compatible
> with existing and future WYSIWYG extensions, all of which will probably
> support template invocation, but most of which will misread [[ :: ]]
> pieces.
>
> >
> > -Yaron
>
>
> --
> Markus Krötzsch
> Semantic MediaWikihttp://semantic-mediawiki.org
> http://korrekt.orgmar...@semantic-mediawiki.org
>
>
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Re: [SMW-devel] Making #set a true semantic call

2009-01-19 Thread Markus Krötzsch 
On Dienstag, 13. Januar 2009, Yaron Koren wrote:
> On Mon, Jan 12, 2009 at 5:25 AM, Markus Krötzsch <
>
> mar...@semantic-mediawiki.org> wrote:
> >  I do not want to contribute to the general
> > interface discussion here,
>
> Well, I'd like to hear your opinion on the issue, if possible - yours is
> obviously the most relevant one.

I don't really think so. I must say that I don't care much about syntax. But 
since you are asking I can explain some technical considerations that I have 
when thinking about new input methods:

* Parsing [[ ]] is not easy and requires us to look through the wiki-text 
string for matching patterns. This causes some issues since the PHP library we 
use crashes on large matches. This is why nested annotations and links were 
disabled. In contrast, parsing {{ }} is done by MediaWiki for us, and nesting 
annotations is not a (technical) problem there.

* Parsing [[ ]] is not clean since it happens at a stage during parsing where 
MediaWiki has half-processed the input. This makes the whole thing somewhat 
messy and undefined. Parsing {{ }} is clearly preferred there, since {{ }} 
have a clear place in the DOM of MediaWiki.

* Parsing annotations requires database lookups, e.g. to get the type of some 
property. Technically, it would be desirable to collect many database calls 
into one (or at least into few). This might be easier with inputs like #set or 
true semantic templates where many inputs are collected within one parser 
function. Annotations spread all over the page would require multiple runs to 
first gather, then jointly parse, and finally output all annotations.

In addition, I think that it is nice if users can see the output SMW gives 
after processing some annotation value (as opposed to #set). For example, this 
could include tooltips, hyperlinks, or warning messages. Some datatypes such 
as Code also provide more complex formating for data, which is rather useful 
to have.

Summing up those four points, and adding my further experience that most SMW 
sites will want to use SemanticForms, I arrive at the following conclusion:


 SMW's primary input mechanism should be an extended form of the current 
semantic templates (#declare). Annotations would be declared (this works 
already) on template pages, so that some parameters get annotated 
automatically without the need of [[ ]] syntax in the template code. Pages 
then simply use the template, provide parameters as usual, and some of the 
latter are turned into annotations and displayed accordingly (this is what 
does not work yet; #declare does not display any SMW output, not even errors).


To do this, someone needs to extend #declare (and the associated processing) 
so that annotated parameters are replaced by the texts that SMW returns when 
processing the values (including error messages and the like). Like the 
current [[ ]] thing, this approach is still universal in the sense that every 
wiki could be modified to use only those "semantic templates" and still would 
look and work exactly the same way. Yet, no more [[ ]] parsing would be needed 
(of course we would keep this as an optional input for backwards 
compatibility). 

-- Markus

P.S. I also think that a syntax with {{ }} is more likely to be compatible 
with existing and future WYSIWYG extensions, all of which will probably 
support template invocation, but most of which will misread [[ :: ]] pieces.

>
> -Yaron


-- 
Markus Krötzsch
Semantic MediaWikihttp://semantic-mediawiki.org
http://korrekt.orgmar...@semantic-mediawiki.org



signature.asc
Description: This is a digitally signed message part.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

[SMW-devel] Fwd: MediaWiki developer meet-up in Berlin, April 3-5

2009-01-19 Thread Yaron Koren 
The MediaWiki developer meet-up... I would have preferred, in the interests
of consistency, that they had called it "ManiaWiki", but so be it. :)
I'm sending this to the users list as well, and not just the developers
list, because at the first SMW users meeting, in Boston in November, there
was somewhat of a consensus that there should be a second meeting sometime
between April and June in Germany. The thought was to hold it in either
Frankfurt or Karlsruhe, but this meet-up might be a good one to latch on to
instead, since there will presumably be people interested in attending both;
it seems like it would work well even for those who aren't developers (they
note in the email that it's really just for anyone interested in the
technical aspects of MediaWiki).

Anyway, if you're interested, just put yourself on that wiki page; you can
sign up as "maybe".

-Yaron


-- Forwarded message --
From: Daniel Kinzler 
Date: Mon, Jan 19, 2009 at 10:58 AM
Subject: [Wikitech-l] MediaWiki developer meet-up in Berlin, April 3-5
To: toolserve...@lists.wikimedia.org, mediawik...@lists.wikimedia.org,
Wikimedia developers ,
wikiresearc...@lists.wikimedia.org


Hello All

I'm happy to announce the MediaWiki Developer Meet-Up will happen April
3.-5. in
Berlin, at the c-base. The event is for everyone who works on MediaWiki,
writes
extensions, builds bots, writes scripts for the toolserver, or is otherwise
interested in the technical aspects of Wikimedia. We are happy that we can
now
have the meet-up after our plans for 25C3 and FOSDEM failed. If you want to
come
to the Developer Meetup, please sign up at
.

The event will take place in parallel to the Wikimedia Foundation's board
meeting and chapter meeting, so there will be a lot of Wikimedians in Berlin
at
the time. We plan to have a party to bring everyone together and give an
opportunity for developers, board members and chapter people to mingle.

The meet-up will be a loose BacCamp-like event so topics and schedule are
largely up to you. The goal is to get to know new aspects of MediaWiki and
Wikimedia and to develop ideas on how we can make things even better. And of
course to have a lot of fun with wiki hackers from around the world!

-- daniel

___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes

2009-01-19 Thread Markus Krötzsch 
On Montag, 19. Januar 2009, zehet...@molgen.mpg.de wrote:
> Hi,
>
> it seems that the field 'mPrefixedText' in a Title object is now empty with
> the new SVN version while previously it contained a value. Is this
> intentionally?

I don't quite understand. The class Title is part of MediaWiki and SMW is not 
changing it at all. To access the prefixed text of some title, use 
getPrefixedText(). This should work in all version of MediaWiki. In any case, 
SMW is not responsible if it fails, I hope ;-)

Cheers,

Markus

>
> Thanks,
> Gu
>
> Quoting Markus Krötzsch :
> > Update:
> >
> > I have tested the current SVN version successfully in combination with
> > SemanticForms and SemanticResultFormats, and we now run it on a number of
> > SMW
> >
> > sites. We might have an intermediate release with this update soon --
> > those who cannot wait may wish to give the current SVN version a try (it
> > can be installed on top of SMW 1.4.* by simply replacing the files).
> >
> > Upgrade is strongly recommended for everybody who experiences "blank
> > pages" (typical for PHP out-of-memory issues) on certain SMW-related
> > operations. The
> >
> > changes can also speed up page display significantly under certain
> > circumstances, especially if inline queries with many results and
> > printouts are used.
> >
> > Cheers,
> >
> > Markus
> >
> > On Freitag, 16. Januar 2009, Markus Krötzsch wrote:
> > > Hi all,
> > >
> > > I have done some debugging of SMW's memory requirements during parsing
> > > and query answering, and I identified a number of issues that lead to
> >
> > increased
> >
> > > memory usage. To fix this, I have modified some parts of the internal
> > > architecture, which I will check into SVN soon.
> > >
> > > In effect, SMW (SVN) is faster and requires less memory, but I also
> > > assume that the changed architecture may still have some bugs. Also,
> > > there might theoretically be minor incompatibilities with SMW
> > > extensions, though I do not expect many such issues since the old
> > > interfaces have been kept unchanged. Yet, SVN users are hereby warned
> > > that some problems might still appear in places. Of course, feedback is
> > > welcome.
> > >
> > > There will be another mail to the developers' list with details.
> > >
> > > Cheers,
> > >
> > > Markus
> >
> > --
> > Markus Krötzsch
> > Semantic MediaWikihttp://semantic-mediawiki.org
> > http://korrekt.orgmar...@semantic-mediawiki.org


-- 
Markus Krötzsch
Semantic MediaWikihttp://semantic-mediawiki.org
http://korrekt.orgmar...@semantic-mediawiki.org



signature.asc
Description: This is a digitally signed message part.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes

2009-01-19 Thread zehetner 
Hi,

it seems that the field 'mPrefixedText' in a Title object is now empty with the
new SVN version while previously it contained a value. Is this intentionally?

Thanks,
Gu

Quoting Markus Krötzsch :

> Update:
> 
> I have tested the current SVN version successfully in combination with 
> SemanticForms and SemanticResultFormats, and we now run it on a number of SMW
> 
> sites. We might have an intermediate release with this update soon -- those 
> who cannot wait may wish to give the current SVN version a try (it can be 
> installed on top of SMW 1.4.* by simply replacing the files).
> 
> Upgrade is strongly recommended for everybody who experiences "blank pages" 
> (typical for PHP out-of-memory issues) on certain SMW-related operations. The
> 
> changes can also speed up page display significantly under certain 
> circumstances, especially if inline queries with many results and printouts 
> are used.
> 
> Cheers,
> 
> Markus
> 
> 
> On Freitag, 16. Januar 2009, Markus Krötzsch wrote:
> > Hi all,
> >
> > I have done some debugging of SMW's memory requirements during parsing and
> > query answering, and I identified a number of issues that lead to
> increased
> > memory usage. To fix this, I have modified some parts of the internal
> > architecture, which I will check into SVN soon.
> >
> > In effect, SMW (SVN) is faster and requires less memory, but I also assume
> > that the changed architecture may still have some bugs. Also, there might
> > theoretically be minor incompatibilities with SMW extensions, though I do
> > not expect many such issues since the old interfaces have been kept
> > unchanged. Yet, SVN users are hereby warned that some problems might still
> > appear in places. Of course, feedback is welcome.
> >
> > There will be another mail to the developers' list with details.
> >
> > Cheers,
> >
> > Markus
> 
> 
> -- 
> Markus Krötzsch
> Semantic MediaWikihttp://semantic-mediawiki.org
> http://korrekt.orgmar...@semantic-mediawiki.org
> 
> 





--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel