Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes
On Dienstag, 20. Januar 2009, zehet...@molgen.mpg.de wrote: 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. This may or may not be related to changes in SMW, but it is generally a non- issue since it is based on a problem in your code that could easily be fixed: just use getPrefixedText() for accessing this value. Direct access to Title's members is not a good design, and it is bound to break sooner or later. As the Title documentation states: * @name Private member variables * Please use the accessor functions instead. Or do you believe in performance improvements based on not calling the accessors? It appears to be unlikely that this has any measurable impact on your application. Even if it had, there would probably be much more effective ways for speeding up things. -- Markus 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 mar...@semantic-mediawiki.org: 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 mar...@semantic-mediawiki.org: 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
Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes
No nothing performance related at all, just pure ignorance and laziness on my part in a quick hack in some extension. Calling getPrefixedText() gives the proper result (with both SMW versions) and also sets the mPrefixedText value in the title object (with the new SMW). You are right, there always comes the time where one has to pay for shortcuts. Thanks, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: On Dienstag, 20. Januar 2009, zehet...@molgen.mpg.de wrote: 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. This may or may not be related to changes in SMW, but it is generally a non- issue since it is based on a problem in your code that could easily be fixed: just use getPrefixedText() for accessing this value. Direct access to Title's members is not a good design, and it is bound to break sooner or later. As the Title documentation states: * @name Private member variables * Please use the accessor functions instead. Or do you believe in performance improvements based on not calling the accessors? It appears to be unlikely that this has any measurable impact on your application. Even if it had, there would probably be much more effective ways for speeding up things. -- Markus 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 mar...@semantic-mediawiki.org: 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 mar...@semantic-mediawiki.org: 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
Re: [SMW-devel] Move #arraymap, #arraymaptemplate into SMW?
Agreed, the arraymaps should be part of SMW. For things like infoboxes,
whether you are using SF or not, you still need to use the arraymap for
annotating lists. So #arraymap is used in far more SMW cases than actual
SF cases.
Actually, on a note, it might be a nice idea to build a sort of #askmap
or something into SMW, or perhaps some kind of format to #ask with some
inline formatting.
{{#ask: [[Category:Character]] [[Classification::Meister]]
[[Weapon::{{PAGENAME}}]] | format=list | replace=$s$ |
inline=[[Meister::$s$]] }}
Say [[Stein]] and [[Kami]] were annotated with [[Weapon::Spirit]]. This
would expand to [[Meister::Stein]] and [[Meister::Kami]] on Spirit's page.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point (http://nadir-point.com)
-Wiki-Tools (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.nadir-point.com)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)
Yaron Koren wrote:
Hi,
I've been thinking recently about components of Semantic Forms that really
belong in Semantic MediaWiki, because they're not related to forms. Special
pages like 'Templates' or 'CreateProperty' are obvious candidates, though
you could make a case for them staying because (a) SF takes a more
template-centric approach, and (b) helper forms are forms in their own
right. But the features of SF for which I don't think any strong case could
be made for keeping them there are the #arraymap and #arraymaptemplate
parser functions, which are used to to map a semantic property or other
action, like a widget call, onto each value of a list. I think it makes
sense to have these somewhere within the SMW system, since SMW takes a
text-as-data approach that isn't shared by most other MediaWiki usages, but
there's nothing form-specific about these functions. In fact, I believe
that in a few cases people have installed Semantic Forms just to have access
to these functions. So, any thoughts on moving them directly into SMW?
I know the general effort is to make SMW as small and lightweight as
possible, but this functionality doesn't take up that much code, and as
someone once said, one should keep things as simple as possible, but no
simpler.
-Yaron
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
--
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
