[Wikitech-l] Re: Help in my tasks in Gerrit

2021-08-14 Thread jp64902
In the Code-Review issue (In the case of +2) I need someone to review these 
changes, which are almost a month since I requested. I confess to worrying a 
little about these stopped changes.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/


[Wikitech-l] [ANN] New DBpedia Snapshot 2021-06

2021-08-14 Thread DBpedia
Apologies for cross-posting. The full release description including 
further statistics can be found on 
https://www.dbpedia.org/blog/snapshot-2021-06-release/ 
.



We are pleased to announce immediate availability of a new edition of 
the free and publicly accessible SPARQL Query Service Endpoint and 
Linked Data Pages, for interacting with the new Snapshot Dataset.



   What is the “DBpedia Snapshot” Release?

Historically, this release has been associated with many names: "DBpedia 
Core", "EN DBpedia", and — most confusingly — just "DBpedia". In fact, 
it is a combination of —


 *

   EN Wikipedia data— A small, but very useful, subset (~ 1 Billion
   triples or 14%) of the whole DBpedia extraction
   using
   theDBpedia Information Extraction Framework
   (DIEF), comprising
   structured information extracted from the English Wikipedia plus
   some enrichments from other Wikipedia language editions, notably
   multilingual abstracts in ar, ca, cs, de, el, eo, es, eu, fr, ga,
   id, it, ja, ko, nl, pl, pt, sv, uk, ru, zh.

 *

   Links— 62 million community-contributed cross-references and
   owl:sameAs links to other linked data sets on the Linked Open Data
   (LOD) Cloud that allow to effectively find and retrieve further
   information from the largest, decentral, change-sensitive knowledge
   graph on earth that has formed around DBpedia since 2007.

 *

   Community extensions— Community-contributed extensions such as
   additional ontologies and taxonomies.


   Release Frequency & Schedule

Going forward, releases will be scheduled for the 15th of February, May, 
July, and October (with +/- 5 days tolerance), and are named using the 
same date convention as the Wikipedia Dumps that served as the basis for 
the release. An example of the release timeline is shown below:



June 6–8



June 8–20



June 20–July 10



July 10–20

Wikipedia dumps for June 1 become available on https://dumps.wikimedia.org/



Download and extraction with DIEF



Post-processing and quality-control period



Linked Data and SPARQL endpoint deployment


   Data Freshness

Given the timeline above, the EN Wikipediadata of DBpedia Snapshot has a 
lag of 1-4 months.



   Further Information

Growth of DBpedia, breakdown of links by domain, download instructions 
and some tips on how to effectively work with DBpedia are published as 
part of this blog post: 
https://www.dbpedia.org/blog/snapshot-2021-06-release/ 






___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Help in my tasks in Gerrit

2021-08-14 Thread Bartosz Dziewoński
For configuration changes (that is, any commit in the 
operations/mediawiki-config repository), you'll need to schedule them to 
be deployed, and then show up on IRC at the scheduled time to verify 
each change works as expected.


Please read https://wikitech.wikimedia.org/wiki/Backport_windows and 
follow the instructions under "How to submit a patch for backport". Thanks!


--
Bartosz Dziewoński
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: reviewer for extension

2021-08-14 Thread tdvit
hello, thanks a lot

for all your feedback.

So I have learned how to submit using "+2" (and I have updated successfully the repository)

I have also asked to change the repository 

from "Merge review" to "Open push" here

 

https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests

 

I understand that with it I could directly push, although I don't think by now is

strictly necessary.

 

I have also reformatted the code which is now here

 

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CIForms/+/3046f62eab32c3dfa0cacf3a11445c936d71451c

 

 

however, I have two issues:

 

1) when I use the command git clone "https://gerrit.wikimedia.org/r/mediawiki/extensions/CIForms"

it also downloads the .git folder, how can I avoid that or to cancel it from the remote folder ?

 

2) from this page https://www.mediawiki.org/wiki/Special:ExtensionDistributor/CIForms

it does not download the updated repository, which is the purpose I aimed for: how can I fix/update it ?

 

thanks

(Thomas)

 

 

 
 

Sent: Saturday, August 14, 2021 at 7:46 AM
From: "Kunal Mehta" 
To: wikitech-l@lists.wikimedia.org
Subject: [Wikitech-l] Re: reviewer for extension

Hi,

On 8/13/21 6:21 AM, Andre Klapper wrote:
> Is this about
> https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CIForms/+/663043
> as that is the only open changeset listed under
> https://gerrit.wikimedia.org/r/q/project:mediawiki/extensions/CIForms ?
>
> I wonder if it makes sense to change the repository in Gerrit from
> "Merge review" to "Open push", assuming you are the sole developer?
> That would allow you to directly push (if I understand correctly).

As a policy reason, we don't allow master/main of MediaWiki
extensions/skins to be open push because it prevents having a space to
discuss the pushed commit. Also, it bypasses any configured CI,
potentially leaving the repo in a broken state.

However, if you're the sole/primary developer of an extension/skin, it's
totally fine to just +2 your own change right after uploading it.

-- Legoktm
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/




 

 ___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Help in my tasks in Gerrit

2021-08-14 Thread Zoran Dori
Hello,
with what exactly do you need help?

Best regards,
Zoran
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/


[Wikitech-l] Re: Goto for microoptimisation

2021-08-14 Thread Robin Hood
Just a minor point about the code: in expandAtributes(), 
$spaceSeparatedListAttributes should be initialized outside the loop or as a 
private static.

From: Krinkle 
Sent: August 13, 2021 11:15 PM
To: For developers discussing technical aspects and organization of Wikimedia 
projects 
Subject: [Wikitech-l] Re: Goto for microoptimisation

For the record, I merged Tim's 
patch last week and 
was unaware of this email thread.

My thinking was as follows:

1. The implementation does not depend on the goto statement.

That is, it is not used to write overly-clever or complicated logic. If you 
remove the goto statement, the method behaves the exact same way. And thus the 
moment it ceases to serve its use (performance optimisation) it can be safely 
removed without further thought. think this is essential to keeping the code 
easy to understand and maintain. This one principle actually covers it all for 
me. The next three points are implied by this:
1a. This use of goto only jumps downward. Jumping backwards (up) would likely 
violate point 1, and either way would imho be too complicated to think about 
when debugging or maintaining the code in the future. Especially the potential 
for an infinite loop.
1b. This use of goto only jumps to a statement within the same function. (In 
fact, jumping to another file, class, or function is not supported by PHP in 
the first place. This is literally the only way it can be used. There is some 
sanity in the language after all!).
1c. This use of goto serves as a performance optimisation for a hot code path. 
Similarly implied by point 1: If it doesn't change behaviour and doesn't 
improve performance where it matters, we shouldn't bother using it.

2. An inline comment clearly stays it is a performance optimisation, and 
explains why it is safe, and how we know the destination is where we would end 
up regardless. (e.g. "we're inside a condition for X2, so we can skip to the 
else of X1, and no other statements would run between here and there").

-- Timo


On Sat, 31 Jul 2021 at 05:10, Tim Starling 
mailto:tstarl...@wikimedia.org>> wrote:

For performance sensitive tight loops, such as parsing and HTML construction, 
to get the best performance it's necessary to think about what PHP is doing on 
an opcode by opcode basis.

Certain flow control patterns cannot be implemented efficiently in PHP without 
using "goto". The current example in Gerrit 
708880
 comes down to:

if ( $x == 1 ) {

  action1();

} else {

  action_not_1();

}

if ( $x == 2 ) {

  action2();

} else {

  action_not_2();

}

If $x==1 is true, we know that the $x==2 comparison is unnecessary and is a 
waste of a couple of VM operations.

It's not feasible to just duplicate the actions, they are not as simple as 
portrayed here and splitting them out to a separate function would incur a 
function call overhead exceeding the proposed benefit.

I am proposing

if ( $x == 1 ) {

  action1();

  goto not_2; // avoid unnecessary comparison $x == 2

} else {

  action_not_1();

}

if ( $x == 2 ) {

  action2();

} else {

  not_2:

  action_not_2();

}

I'm familiar with the cultivated distaste for goto. Some people are just 
parotting the textbook or their preferred authority, and others are scarred by 
experience with other languages such as old BASIC dialects. But I don't think 
either rationale really holds up to scrutiny.

I think goto is often easier to read than workarounds for the lack of goto. For 
example, maybe you could do the current example with break:

do {

  do {

 if ( $x === 1 ) {

 action1();

 break;

 } else {

 action_not_1();

 }

 if ( $x === 2 ) {

 action2();

 break 2;

 }

  } while ( false );

  action_not_2();

} while ( false );

But I don't think that's an improvement for readability.

You can certainly use goto in a way that makes things unreadable, but that goes 
for a lot of things.

I am requesting that goto be considered acceptable for micro-optimisation.

When performance is not a concern, abstractions can be introduced which 
restructure the code so that it flows in a more conventional way. I understand 
that you might do a double-take when you see "goto" in a function. 
Unfamiliarity slows down comprehension. That's why I'm suggesting that it only 
be used when there is a performance justification.

-- Tim Starling
___
Wikitech-l mailing list -- 
wikitech-l@lists.wikimedia.org
To unsubscribe send an email to 
wikitech-l-le...@lists.wikimedia.org