Active Topics
-
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 3 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 16 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 15 hrs ago - more...
|
2018-02-07
, 08:57
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#22
|
Originally Posted by acrux
Are you sure that swiften 4.0 (beta) doesn't support MAM? https://github.com/swift/swift/searc...utf8=%E2%9C%93
Are you sure that using swiften is a good idea?
1. It does not support simultaneous connections to several accounts.
Actually there was a question about that in swift mailing list and the answer was that: "Noted, thanks - it’s on the list and Daniel (one of our GSoC students) is looking at this over the summer." However the summer was the 2015 one...
2. It does not support XEP-0313: Message Archive Management. Can't imagine a multiuser chat where you see only those messages when you are present...
The best one is probably Conversations (android) and in the Linux desktop area Gajim (pygtk). Also Psi (qt5) says that XEP-0313 will be supported in version 2.0 (currently 1.3).
|
|
2018-02-07
, 09:26
|
|
Posts: 287 |
Thanked: 618 times |
Joined on Jan 2011
@ Estonia
|
#23
|
Originally Posted by marmistrz
Hmm, testing here Swift-4.0rc5.amd64.appimage and yes, message archive management is definitely not working.
Are you sure that swiften 4.0 (beta) doesn't support MAM? https://github.com/swift/swift/searc...utf8=%E2%9C%93
|
|
2018-02-07
, 10:54
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#24
|
Originally Posted by marmistrz
At work I'm one of the people who maintain & develop the Anaconda installer used by Fedora/RHEL/CentOS and other distributions. Anaconda has a sizeable codebase with a history getting back to 1999. but we don't really see any special Python related issues compared to if it was written in a different language and we can maintain it just fine.
Are you sure that using python is a good idea?
I'm not talking performance here. I mean the maintainability. I've worked on a 50+KLOC python project and maintaining a bigger python codebase is a nightmare.
It's certainly true that due to the awesome flexibility and dynamic nature of Python you don't get some of the benefits of static type checking and linting overall is hard to implement (though Pylint is already doing a pretty well & improving).
On the other hand I think the static type checking provided by strongly typed languages is overrated - it will find only the most trivial issues, while any real mistakes in the application logic will still show up at only at runtime. So you still need a comprehensive test suite either way & it seems to be less and less acceptable these days to develop nontrivial suftware without having a good test coverage and using CI.
Also in the Sailfish OS perspective - we have Python 3.4 (letst stable is 3.6), which compared to the ancient GCC version (4.8 I think ?) is substantially newer and should thus enable the use of resonably modern Python features, unlike with the default C/C++ compiler.
So I don't really see any real issues with using Python on this and I think it's a really good choice given the current state of the Sailfish OS toolchain.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
| The Following 4 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2018-02-07
, 11:04
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#25
|
Originally Posted by MartinK
https://github.com/PyCQA/pylint/issues/1646
though Pylint is already doing a pretty well & improving
https://github.com/PyCQA/pylint/issues/1651
https://github.com/PyCQA/pylint/issues/1660
https://github.com/PyCQA/pylint/issues/1631
https://github.com/PyCQA/pylint/issues/1630
This was more than enough to drop obligatory pylint check at work. Especially the first issue.
Originally Posted by MartinK
Just as an integral of a small function over a big set, if you have a lot of small, trivial bugs, that could be easily caught - that's a big burden.
On the other hand I think the static type checking provided by strongly typed languages is overrated - it will find only the most trivial issues, while any real mistakes in the application logic will still show up at only at runtime.
As for the static checking in C++, yes, this is often not enough. Enter Rust!
Also in the Sailfish OS perspective - we have Python 3.4 (letst stable is 3.6), which compared to the ancient GCC version (4.8 I think ?) is substantially newer and should thus enable the use of resonably modern Python features, unlike with the default C/C++ compiler.
So I don't really see any real issues with using Python on this and I think it's a really good choice given the current state of the Sailfish OS toolchain.
| The Following 3 Users Say Thank You to marmistrz For This Useful Post: | ||
|
|
2018-02-07
, 18:18
|
|
Posts: 24 |
Thanked: 142 times |
Joined on Jan 2017
@ \
|
#26
|
The discussing Python vs C++, every language has his pro and cons.
I already made some prototyping for the modules in Python which works fine. I'm also trying the implement the same thing in Qt C++ to check out which way is the best one.
Currently I'm stuck a little bit between the 2 languages since I'm considering to add 3rd party support (at least the basis to do that) and this has pro and cons for both languages.
I already made some prototyping for the modules in Python which works fine. I'm also trying the implement the same thing in Qt C++ to check out which way is the best one.
Currently I'm stuck a little bit between the 2 languages since I'm considering to add 3rd party support (at least the basis to do that) and this has pro and cons for both languages.
| The Following 3 Users Say Thank You to Modulebaan For This Useful Post: | ||
|
|
2018-02-07
, 18:26
|
|
Posts: 9 |
Thanked: 82 times |
Joined on Dec 2016
@ 127.0.0.1
|
#27
|
On 1)
I have not looked into the code about this until now. Someone will find this feature usefull, someone have only one account. It depends on the personal usage.
On 2)
MUC didn't need xep-0313 to work correctly in the client. The last recent messages of a group chat are stored on the server and will be send to clients which where offline. This is trivial implemented without the need of message archive management.
I have not looked into the code about this until now. Someone will find this feature usefull, someone have only one account. It depends on the personal usage.
On 2)
MUC didn't need xep-0313 to work correctly in the client. The last recent messages of a group chat are stored on the server and will be send to clients which where offline. This is trivial implemented without the need of message archive management.
Originally Posted by acrux
Are you sure that using swiften is a good idea?
1. It does not support simultaneous connections to several accounts.
Actually there was a question about that in swift mailing list and the answer was that: "Noted, thanks - it’s on the list and Daniel (one of our GSoC students) is looking at this over the summer." However the summer was the 2015 one...
2. It does not support XEP-0313: Message Archive Management. Can't imagine a multiuser chat where you see only those messages when you are present...
|
|
2018-02-07
, 18:34
|
|
Posts: 9 |
Thanked: 82 times |
Joined on Dec 2016
@ 127.0.0.1
|
#28
|
In my opinion it is also not a thing python vs c++. When I start a project I have a look at the available frameworks and librarys which are available to handle the features I need. I think that should make the decision. It's very hard to write most things again from scratch.
Personally I would not start to work on such a framework. The linked discussion on gnome mailing list about telpathy says all about this approach.
But hey, this is open source. Everyone who has a need is free to implement things that make his life easier. I wish you all success with Transponder!
Personally I would not start to work on such a framework. The linked discussion on gnome mailing list about telpathy says all about this approach.
But hey, this is open source. Everyone who has a need is free to implement things that make his life easier. I wish you all success with Transponder!
|
|
2018-02-07
, 21:09
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#29
|
schorsch, still, I think that we'll need to come around MAM sooner or later, anyway. I often receive some links on the phone but want to view than on the computer.
So this will wind up as writing PRs against swiften. Not saying that it's not the best solution here, I don't know the alternatives.
/edit: from the Conversations channel:
Last edited by marmistrz; 2018-02-07 at 21:39.
So this will wind up as writing PRs against swiften. Not saying that it's not the best solution here, I don't know the alternatives.
/edit: from the Conversations channel:
looks like it's been worked on at least since 2014: https://github.com/swift/swift/commi...fd446d6fc8cda8
though that commit is in 3.0 as well. Maybe it's broken?
__________________
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
Last edited by marmistrz; 2018-02-07 at 21:39.
|
|
2018-02-08
, 08:39
|
|
Posts: 287 |
Thanked: 618 times |
Joined on Jan 2011
@ Estonia
|
#30
|
Originally Posted by schorsch
Yes, to some extent it works. But my experience shows that this is not very reliable. Not to say, that when server is restarted, then everything is lost. Sometimes my own text is missing at all etc... Maybe it can be configured to your need when you have a full control to the server yourself...
MUC didn't need xep-0313 to work correctly in the client. The last recent messages of a group chat are stored on the server and will be send to clients which where offline. This is trivial implemented without the need of message archive management.
| The Following 4 Users Say Thank You to acrux For This Useful Post: | ||
 |
| Tags |
| messaging, native, python, sailfish os, telepathy |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 12:52.
1. It does not support simultaneous connections to several accounts.
Actually there was a question about that in swift mailing list and the answer was that: "Noted, thanks - it’s on the list and Daniel (one of our GSoC students) is looking at this over the summer." However the summer was the 2015 one...
2. It does not support XEP-0313: Message Archive Management. Can't imagine a multiuser chat where you see only those messages when you are present...
The best one is probably Conversations (android) and in the Linux desktop area Gajim (pygtk). Also Psi (qt5) says that XEP-0313 will be supported in version 2.0 (currently 1.3).