Hi!
Together with Nicolas we are trying to get all the <script …> … </script> from html files.
We have tried to use XMLDOMParser, but many webpages are actually not well formed, therefore the parser is complaining.
Anyone has tried to get some particular tags from HTML files? This looks like a classical thing to do. Maybe some of you have done it.
Is there a way to configure the parser to accept a broken XML/HTML content?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
Look at the class side, there is the method parse: namespace: validation: . call this method instead of parse: with false in the two last arguments. It should work.
Anyway, you should use the sax parser. It is faster and memory less consuming. It is very simple to get only one tag.
Cheers
Vincent
Le 14 août 2015 01:31, Alexandre Bergel <alexandre.bergel(a)me.com> a écrit :
>
> Hi!
>
> Together with Nicolas we are trying to get all the <script …> … </script> from html files.
> We have tried to use XMLDOMParser, but many webpages are actually not well formed, therefore the parser is complaining.
>
> Anyone has tried to get some particular tags from HTML files? This looks like a classical thing to do. Maybe some of you have done it.
> Is there a way to configure the parser to accept a broken XML/HTML content?
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi!
Am I the only one to experience image freeze? Especially when I load from Monticello.
cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
Roassal has a new builder called RTDSM.
It is currently very basic. Here is an example:
dsm := RTDSM new.
dsm objects: RTShape withAllSubclasses.
dsm dependency: #dependentClasses.
produces the following:
Are there some algorithms to find an optimal ordering of the elements to display?
Here is a slightly bigger matrix
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
In progress:
x. Export Google Issues to JSON since we have too many to use the Export
button
x. Create GH access token for Python import script
x. Request GH raise our API rate limit so that script doesn't fall over so
frequently
4. Re-run script to import remaining (almost all) issues
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Moving-Issues-to-GitHub-tp4840767.html
Sent from the Moose mailing list archive at Nabble.com.
Hi,
I would like to know why it is implemented like that:
Collection>>mooseDisplayStringOn: stream
stream print: self size.
self isEmpty
ifTrue: [ stream nextPutAll: ' items' ].
self size = 1
ifTrue: [ stream nextPutAll: ' item' ].
self size > 1
ifTrue: [ stream nextPutAll: ' items' ].
Because we get this kind of result:
[cid:image006.png@01D0D397.86F21980]
Which is not very easy to read... Can I change it or is there a performance issue?
Cheers,
Vincent BLONDEAU
RMOD Team
Bât B - Bureau 306
Centre de recherche
Lille-Nord Europe
+33 (0)3 59 35 87 45
vincent.blondeau(a)inria.fr<mailto:vincent.blondeau@inria.fr>
[cid:image001.jpg@01D0D396.C12C3780]
Software Architects
SDCO
ZI A, rue de la Pointe
59113 SECLIN
+33.(0)3.28.54.41.54
vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>
[cid:image003.gif@01D0D396.C12C3780]
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Big big issue! I get an error with the BLFormatter or something.
Juraj, how can I manually choose to send spotter data?
I have not tried whether in Pharo 5 I have the same error or not.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
Thanks to Joachim, JNIPort now works on Pharo 5, and Jdt2Famix now works on
Moose 6.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
I started writing a basic woden loading tutorial: http://woden.ronie.cl/
Please, bear in mind that this is an early draft, so expect lot of mistakes.
Greetings,
Ronie
Hi,
I would like to announce the jdt2famix project. This aims to be an
open-source solution for importing Java projects into Moose:
http://www.smalltalkhub.com/#!/~Moose/Jdt2Famix
The project is based on:
- JDT for raw parsing. This is implemented in Java.
- JNIPort for delegating to Pharo the Java methods that visit the Java AST.
Installation details can be found on the main project page.
The current importing logic is rudimentary, but the first goal was to setup
the whole ping-pong between Pharo and Java. This one works, and I am quite
happy about that. You can take a look at the JdtImporterTest.
CAVEATS:
- Due to a problem in JNIPort, currently, this project only works in Moose
5.0.
- Also, for now it works out of the box only for Mac OS X.
- And, on top of that, it requires Java 1.6 for now (until we will get the
Spur VM on 64 bits).
There are still quite some challenges left, but once we get this going, we
would also be able to use deep AST analysis live, and to do incremental
model update when something changes on disk. Furthermore, if it scales,
this would not be based on an intermediary MSE file anymore.
I would like to ask for help in several directions:
1. Implement the full model import. This would require diving into JDT and
implementing the corresponding mapping logic. I spent a few days on this.
It is hairy, but it is not that impossible (only it has a ton of edge
cases). This should be test driven, in that, for each case, we need to have
a corresponding sample.
2. Fix JNIPort to work in Pharo 5.
3. Get the whole thing to work out of the box for Linux and Windows.
4. Check scalability.
Please let me know your opinions, and let me know if you would like to
participate.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"