This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
91
Issues Help Desk / Re: Error opening the ENIGMA - Illegal character
« on: September 10, 2015, 03:15:52 am »
It's probably in "recent files"? I think LGM might not support something in that list. Is there a way to clear that list outside LGM? I think it saves that in Registry (most programs save that list in Windows registry).
92
Issues Help Desk / Re: Error opening the ENIGMA - Illegal character
« on: September 09, 2015, 01:37:03 pm »
Maybe it is the space character in path?
93
Proposals / Re: Editor Enhancement
« on: September 08, 2015, 06:00:31 am »
Can't you just make everything draggable so people can decide?
94
Issues Help Desk / Re: How to install and run Enigma
« on: September 07, 2015, 03:46:13 pm »
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) Client VM (build 25.45-b02, mixed mode)
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) Client VM (build 25.45-b02, mixed mode)
95
Issues Help Desk / Re: How to install and run Enigma
« on: September 07, 2015, 05:29:23 am »
What is the error exactly? I have windows 10 and everything works.
96
Developing ENIGMA / Re: Migrate Releases
« on: September 05, 2015, 07:14:50 pm »
We often don't have nice list of changes in the commit logs either. It is usually just named "fixes" or something with only the most grand change added in the title. I have been trying to make the changes a lot prettier though with listing. Like all the commits in the past few years from me have been in a form of:
-New feature
-Change
-Bug fix
And so on. Sometimes I include additional information so some of the bullet-points can get larger. In a log that would not be needed.
And I don't agree with the "we would literally be revising our own revision logs" as we are still doing it manually anyway. If you want to include a changelog in a release, then you will have to manually assemble it. And for each release add the new changes. If you are going to do that process anyway then why not include the .txt in the git repo? Then we could at least automate building of installer and you wouldn't loose it.
So the automagic generation of logs is only possible if create one commit per change. And git committing is actually something we haven't discussed anyway. We have some kind of style guide for source, but how about style guide for git? Like:
1) Every change in a separate commit.
2) Change must be described in title of commit message.
3) More details or notes can be done in description of commit message.
4) Don't bundle several changes together in one commit.
5) Master should work (compile and run) after each commit.
I would personally not like these points, as I cannot guarantee (5) while working in a branch and I usually can't guarantee (4) and (1) because sometimes I can't separate changes. Like I add 5 new functions in GSstdraw.cpp. I can't make 5 commits for that file unless I commit after each function add. That slows down development.
Maybe Josh has some interesting ideas here? Like how is he used to work in G or something? I think they use Git too.
-New feature
-Change
-Bug fix
And so on. Sometimes I include additional information so some of the bullet-points can get larger. In a log that would not be needed.
Quote
but I see no reason to add it to revision control, we would literally be revising our own revision logs (is this not what git should be doing for us?)As far as I know git can only generate a log with "git log --oneline --decorate --color". The log shows only the commits and their titles though. Not the full message. So this would only work if we do every single small change in a separate commit. That is something we usually don't do and I'm also sometimes doing so many things in parallel a single commit can have 40 changes.
And I don't agree with the "we would literally be revising our own revision logs" as we are still doing it manually anyway. If you want to include a changelog in a release, then you will have to manually assemble it. And for each release add the new changes. If you are going to do that process anyway then why not include the .txt in the git repo? Then we could at least automate building of installer and you wouldn't loose it.
So the automagic generation of logs is only possible if create one commit per change. And git committing is actually something we haven't discussed anyway. We have some kind of style guide for source, but how about style guide for git? Like:
1) Every change in a separate commit.
2) Change must be described in title of commit message.
3) More details or notes can be done in description of commit message.
4) Don't bundle several changes together in one commit.
5) Master should work (compile and run) after each commit.
I would personally not like these points, as I cannot guarantee (5) while working in a branch and I usually can't guarantee (4) and (1) because sometimes I can't separate changes. Like I add 5 new functions in GSstdraw.cpp. I can't make 5 commits for that file unless I commit after each function add. That slows down development.
Maybe Josh has some interesting ideas here? Like how is he used to work in G or something? I think they use Git too.
97
Developing ENIGMA / Re: Migrate Releases
« on: September 05, 2015, 08:20:05 am »Quote
The problem with this is that if the release log is verbose/long then it is really hard to browse for other releases. The simple thing is to say to just make the release log shorter but that's not always feasible. The other solution is to make more frequent releases so the logs stay smaller. Personally I think GitHub should improve the releases feature by making the browse part short descriptions then clicking on the release gives a change log and a longer description, maybe I'll file an enhancement request/suggestion. Though I doubt they'll care what I think since they don't even listen to Linux Torvalds who created git.That is not what I meant. I meant adding a changelog.txt in the repo so that when the person downloads ENIGMA.zip he has that inside the ENIGMA folder. This way he can always see what has changed (and there could be a million changes all we care) and yet the GIT releases are a lot more concise and don't show all the changes like you want.
98
Developing ENIGMA / Re: Debuging the .dll
« on: September 05, 2015, 08:11:25 am »
It is useful if the users have the bugs as we can make some kind of autoreport system. But it is not useful for us or developers as we can just compile in debug mode.
99
Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 03:40:08 pm »
Maybe we need to add a changelog in the repo as well, so that when a person downloads the release from github he can still see what has changed (even if the forum dies for example).
And how do we start versioning ENIGMA? Just start at 1 or something? I personally think ENIGMA is working enough to actually be considered version 1 right now (except the LGM crashes). And then just go from there. I kind of liked smaller versions previously (like 1.21, 1.22, 1.3 etc.) but it seems the current trend for a few years now is just increment the version by 1. So we get firefox 40.0.3 now and so on. So the after dot revisions are bugfixes and almost every feature is a major revision.
We should also create milestones, so we know when to release instead of on every commit.
Also, can github create a release for the current master automatically? Like instead of a specific version release the top one is always the current up-to-date one (like "beta" releases). I guess all of that must be done manually?
And how do we start versioning ENIGMA? Just start at 1 or something? I personally think ENIGMA is working enough to actually be considered version 1 right now (except the LGM crashes). And then just go from there. I kind of liked smaller versions previously (like 1.21, 1.22, 1.3 etc.) but it seems the current trend for a few years now is just increment the version by 1. So we get firefox 40.0.3 now and so on. So the after dot revisions are bugfixes and almost every feature is a major revision.
We should also create milestones, so we know when to release instead of on every commit.
Also, can github create a release for the current master automatically? Like instead of a specific version release the top one is always the current up-to-date one (like "beta" releases). I guess all of that must be done manually?
100
Developing ENIGMA / Re: Debuging the .dll
« on: September 04, 2015, 03:30:27 pm »
It seems that fixed bugs on my laptop, but on my PC it still crashes as usual.
101
Developing ENIGMA / Re: Debuging the .dll
« on: September 04, 2015, 10:42:56 am »
We are using JNA. The fixes I did was in the plugin code (JDI, the parser).
102
Developing ENIGMA / Re: Debuging the .dll
« on: September 04, 2015, 06:26:03 am »
By the way an example of problems the plugin has can be seen here: https://github.com/enigma-dev/enigma-dev/commit/6d6687824d1d6484c718b21d2ba6b31d80780d18
I fixed that null pointer nonsense and it reduced LGM crashes to almost zero on my laptop. More testing needed though. But the fact that a lot of code is so unsafe in the plugin is the reason why so many crashes happen.
I fixed that null pointer nonsense and it reduced LGM crashes to almost zero on my laptop. More testing needed though. But the fact that a lot of code is so unsafe in the plugin is the reason why so many crashes happen.
103
Programming Help / Re: Am I using the BasicGUI extension correctly?
« on: September 03, 2015, 06:05:47 pm »
No, not yet, sorry. There are currently 262 BasicGUI functions. Even if I document them all I don't know if that will make using it any easier. I think need to create a lot of examples first. A person will be able to learn a lot more by looking at code than at the docs.
104
Programming Help / Re: date_date_string change format
« on: September 03, 2015, 06:14:51 am »Quote
Yeah but still I documented it to.I only see date_datetime_string, but no date_datetime_stringf. So I don't see how it is documented.
105
Developing ENIGMA / Re: Migrate Releases
« on: September 02, 2015, 01:56:21 pm »
I totally agree with this. I haven't made GitHub release myself, but I have used them and I like it. I think it is super cool if it allows automatic changelog creation, as currently I do it manually by looking at commits.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »