Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Stephen Lyons
@SlySven
I am trying to get the lua subsystem operable on my Windows install and decided I wanted a way to permanently doctor the starting package.cpath and package.path - I can set them now via a special option (not yet stored in the main QSettings) but I cannot find out (get) what the current values are to populate a pair of QLineEdits for the dlgProfilePreferences dialog.
Vadim Peretokin
@vadi2

Surprise release! Consider this a Christmas present. We found an important bug with the colour triggers and we've fixed it promptly for you, plus added a ton of other goodies!

Read all about it: https://www.mudlet.org/2017/12/mudlet-3-7-0-colour-triggers-fixed-default-profiles-can-be-deleted

@SlySven "package.path" as a global will not work. You first have to get package, then path...
Is this really an option the user needs to be able to configure? Mudlet should know this
Stephen Lyons
@SlySven
It is very definitely a developer centred option with relevance to Windows (and other platforms); the former because there is no single standard place for lua libraries and modules and being able to hack them at run-time is easier than hacking the source code, recompiling and then finding a run-time lua component is still not loading; and on the latter even more hacking might be needed during the porting process (I'm thinking about my attempts to port to Cygwin and FreeBSD - both of which are stalling at getting the run-time lua stuff working). Of course once a developer has worked out what is needed then the tweaks can be probably be ported into the code as platform specific settings. I intend to have them as a couple of QLineEdits in a QGroupBox(with the checkBox) on the "Special Options" tab. If the checkBox is checked on "save"-ing the dialogue then the changes are saved into the main QSettings and re-used for future profile loads - :bulb: but there will then need to be a reset button as well to reset to the compiled in defaults that we have currently.
Stephen Lyons
@SlySven
My only issue at present is that I cannot find out from the C++ side what the blooming settings are currently (I can write them!). Hell, I've even asked on Stack Exchange...
Stephen Lyons
@SlySven
@vadi2 have a look at #1484 - does it scratch your itch about update notification and access to the updates on the main menu bar? It only covers Windows and Linux - you may be able to extend it to cover the macOS but working on the Sparkle stuff for that is beyond my ken.
Vadim Peretokin
@vadi2
@SlySven you do not need to recompile Mudlet to get updated Lua code in, we removed that years ago.
Vadim Peretokin
@vadi2
I pretty much spent the entire day on Mudlet today and I had to do a bugfix release to a bugfix release. Ouch.
Stephen Lyons
@SlySven

@ SlySven you do not need to recompile Mudlet to get updated Lua code in, we removed that years ago.

You do if the hard-coded paths that are used to load in the LuaCore.lua i.e. in (void) TLuaInterpreter::loadGlobal() and the other run-time modules in the bottom of (void) TLuaInterpreter::initLuaGlobals() are not working on your platform... - this is to make it easier to debug and fix things in those areas.

Vadim Peretokin
@vadi2
Okay, as long as it doesn't get in the way for the users, so some sort of a hidden option to make your life easier.
Vadim Peretokin
@vadi2
@SlySven hey how come you undid my windows compiling changes in https://wiki.mudlet.org/index.php?title=Compiling_Mudlet&type=revision&diff=4215&oldid=4213 ? I simplified the process a lot by making it be a few commands people could copy/paste and now all that is gone...
Vadim Peretokin
@vadi2

Hey, Reinos de Leyenda switched over from their MudletRL fork to the official Mudlet: https://www.reinosdeleyenda.es/blog/nueva-version-de-mudletrl

Thanks @SlySven for porting their changes :)

Stephen Lyons
@SlySven

@ SlySven hey how come you undid my windows compiling changes

I'd found they were out of date and some tweaking/explaining was necessary for me to get things to compile; I suppose it would be possible to copy the active lines and re-paste them below as two blocks of commands to paste and run... though as I see that libzip has been updated to 1.4.0 perhaps that bug in 1.3.1 and 1.3.2 has been fixed as I anticipate so it can be just one block.

Stephen Lyons
@SlySven
Hope you don't mind my switch from using powershell commands to edit various files to using sedones which are a little more comprehensible (I think).
Vadim Peretokin
@vadi2
@SlySven sed was corrupting files, that's why I had to go for the complicated powershell
It would be nice if it was just a block of code people can copy/paste and run as it was before - much simpler!
Stephen Lyons
@SlySven
Um, there isn't any quotes in the strings that are being search/replaced so I am not sure if that is an issue. I'll check again and also see if libzip now compiles out of the box...
Stephen Lyons
@SlySven
Oh, bugger, the people over at libzip have retired (as of 2017/12/08) using the autotools build system for libzip as of 1.4.0 and there I was hoping they'd have fixed an issue with using that system on 1.3.1 and 1.3.2 - guess I'll have to see if I can rejig the Windows build instructions to use CMake for that now...
Vadim Peretokin
@vadi2
Ah
Okay
Vadim Peretokin
@vadi2
Someone made some rpmlint(?) fixes: kurumushi/Mudlet@ebadbb2
Vadim Peretokin
@vadi2
Vadim Peretokin
@vadi2
now this is a cool library! https://github.com/Naios/continuable
nice to see these constructs from javascript come over to c++
Stephen Lyons
@SlySven

Humm, AppVeyor keeps bugging out - at least for #1539 - the log is ending by saying:

[00:06:58] ==== compiling and installing zziplib ====
[00:06:58] ---- Downloading ----
[00:07:00] ---- Extracting source distribution ----
[00:07:02] ---- changing configure script ----
[00:07:02] ---- Running configure ----
[00:07:41] ---- Running make ----
[00:08:17] ---- Running make install ----
[00:08:25] ==== zziplib compiled and installed ====
[00:08:25] ==== compiling and installing luarocks ====
[00:08:25] ---- Downloading ----
[00:08:26] Exception calling "DownloadFile" with "2" argument(s): "The request was
[00:08:26] aborted: Could not create SSL/TLS secure channel."
[00:08:26] At C:\projects\mudlet\CI\appveyor.install.ps1:75 char:3
[00:08:26] + (New-Object System.Net.WebClient).DownloadFile($url, "$workingBaseD ...
[00:08:26] + ~~~~~~~~~~~~~~~
[00:08:26] + CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordE
[00:08:26] xception
[00:08:26] + FullyQualifiedErrorId : WebException
[00:08:26]
[00:08:26] Command exited with code 1
[00:08:26] cd C:\src
[00:08:26] bash -c "curl --upload-file ./verbose_output.log https://transfer.sh/verbose_output.log"
[00:08:26] % Total % Received % Xferd Average Speed Time Time Time Current
[00:08:26] Dload Upload Total Spent Left Speed
[00:08:26]
[00:08:27] 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
[00:08:28] 13 699k 0 0 13 98304 0 98304 0:00:07 0:00:01 0:00:06 93980
[00:08:29] 96 699k 0 0 96 672k 0 336k 0:00:02 0:00:02 --:--:-- 328k
[00:08:29] 100 699k 100 44 100 699k 22 349k 0:00:02 0:00:02 --:--:-- 248k
https://transfer.sh/bNZYM/verbose_output.log

It was working yesterday for #1357 ... :cry:
Stephen Lyons
@SlySven
:exclamation: It has failed in the same way for #1357 now I merged it into the development branch - and there should be no difference between how the code would be in the test for the PR (which ran fine on AppVeyor yesterday) and the build now for the updated branch so I think there is an AppVayor system problem although it's status page is not currently showing any issues. :hankey:
Vadim Peretokin
@vadi2
Yeah, or maybe it's an issue with the luarocks website?
It is an HTTPS error after all @SlySven
Stephen Lyons
@SlySven
For whom - the Kepler people who host lua things?
Vadim Peretokin
@vadi2
Yeah
Also, unrelated to this - I have an idea - for some of the Frankenstein PRs that are taking a long while to get through, what about having a voice call where we can resolve all the issues much quicker?
Stephen Lyons
@SlySven
Doesn't look like Voice is supported for *nix OSes...
... on discord I mean - hell this is confusing I've got both Gitter and now Discord open...
Vadim Peretokin
@vadi2
Voice is supported, I use it regularly!
Even desktop sharing works. You just need to use the installed app, not the web version
Stephen Lyons
@SlySven
Let me find a microphone...
:wave: bye on Gitter...
Vadim Peretokin
@vadi2
See you there
Stephen Lyons
@SlySven

Interesting - I have been invited to participate in an academic research project (by a Fabio Thomaz Molinar at Liverpool University, UK) about the effectiveness of Gitter as a team communications tool for F.O.S.S. projects. I was just going to comment about how we have jumped ship to Discord but actually I think there is still a place for Gitter - because the traffic here is much more development orientated and there is (IMHO) good links to Github - although that is not really THAT surprising.

Anyhow - I am not going to put the lights off here just yet...!

keneanung
@keneanung
Nor do we. But the larger user base on discord makes sense to have discussion there. It also serves transparency
Ahmed Charles
@ahmedcharles
I'd hypothesize that having two communities is ideal. A user community that provides feedback and a development community that fosters contribution with a focus on producing a product for the previous community.
Stephen Lyons
@SlySven
Right - having merged #1570, that leaves these PRs that I have open that I think are good to go: #1543, #1563, #1565, #1571 - I have one more one that I'd like to get into 3.8.0 if possible but I still have some details to finish and that is the one to clean up the selection/highlighting on screen when the glyphs are not of uniform widths and/or use more than one QChar to represent them - I think I have the display and selection of text by mouse sorted but I need to do some more checking...
Stephen Lyons
@SlySven
Got the results from that Academic Study I mentioned above, it is at: http://bit.ly/gitter-guidelines - and I think there are one or two guilde-lines that might be helpful to us...
tiger92665
@tiger92665
hello ,one question, does the mudlet support chinese charset gbk18030 or gb2312 ?
Stephen Lyons
@SlySven

I thought I already had got the support for GB18030 and GBK (a sucessor to GB2312) MUD Server encoding into Mudlet (in Mudlet/Mudlet#1553 , although there is an issue with the characters that the Unicode organisation says have an ambiguous width (with a recent change they are assumed to be wide by default if the encoding is set to either of those but narrow otherwise - but they can be force to either manually if necessary).

The code to handle selection and highlighting for non ASCII characters by lua scripts or by trigger matching is still being worked on and I am not a 100% certain that it is fully functional.

The GUI is fixed in English at the moment but work had already started to translate it - we are looking for volunteers who are bilingual in English and another language - and we do need some who speak languages of the Mid and Far East parts of the World - if you feel you can contribute I feel sure we would welcome your input...

Also, be advised that the most rapid responses are likely to be found on our Discord channels, since we opened that up a few months ago things have gone very quiet on Gitter... :frown:
Kebap
@Kebap
OK just to reiterate: After >1 year testing, we have settled on Discord, and removed mentions of Gitter everywhere. See you there (or in our forums, github, twitter, etc. other venues listed on mudlet.org website) :wave: