Re: [poll] Moving all RFCs in a separate repo
-1 if it stays the way it is (it really messed up my Github profile, as I later realized), but I'm not against rfcs repo per se.| ---|--- I agree with the comments that we should review the existing proposals and close the ones that do not satisfy some minimal criteria or are not relevant any more. (Not just close everything) I really like the idea of templates, both for RFCs and for issues.
Re: How to customize docgen css?
I had opened an issue regarding dochack.js for the Nim docs website. That is
now resolved, but this is a different issue.
I finally got the search working for [my repo
here](https://kaushalmodi.github.io/elnim/). I have the solution portable in
the form of a `docs` NimScript task.
from ospaths import `/`, splitPath
from strutils import `%`
switch("nep1", "on")
let
root = thisDir()
(_, pkgName) = root.splitPath()
srcFile = root / "src" / (pkgName & ".nim")
task docs, "Deploy doc html + search index to public/ directory":
let
deployDir = root / "public"
deployHtmlFile = deployDir / "index.html"
deployIdxFile = deployDir / (pkgName & ".idx")
deployJsFile = deployDir / "dochack.js"
genDocCmd = "nim doc --index:on -o:$1 $2" % [deployHtmlFile, srcFile]
sedCmd = "sed -i 's|" & pkgName & r"\.html|index.html|' " &
deployIdxFile
genTheIndexCmd = "nim buildIndex -o:$1/theindex.html $1" % [deployDir]
docHackJsSource = "http://nim-lang.github.io/Nim/dochack.js"; # devel
docs dochack.js
mkDir(deployDir)
exec(genDocCmd)
exec(sedCmd) # Hack: replace pkgName.html with index.html in the .idx file
exec(genTheIndexCmd) # Generate theindex.html only after fixing the .idx
file
if not fileExists(deployJsFile):
withDir deployDir:
exec("curl -LO " & docHackJsSource)
Run
[Source
config.nims](https://github.com/kaushalmodi/elnim/blob/e4840e44fcfae677ce51bd3eb839af063390ae24/config.nims)
Re: [poll] Moving all RFCs in a separate repo
Ok, I have switched my vote from that on IRC. It's a -1 from me too: > Looking in only one place is better, and it's better for code linking as well > so -1. This is really useful. As for low barrier for entry for RFCs, may be just be quick to pull trigger on closing bad/incomplete RFCs?
Re: [poll] Moving all RFCs in a separate repo
Looking in only one place is better, and it's better for code linking as well so -1. However more aggressive closing and a Github template that should basically tell: > ## RFCs (Request for Comments/Changes) > > We welcome Nim enhancement proposals, while there is no minimum please ensure > that the current context, how you see your proposal improves it and an > expected transition if it's not backward compatible are documented. Here are > some examples of RFCs 1, 2, and 3 that though different, illustrates what > kind of proposals we are looking for. We might close your proposal until > further rework, for that we're sorry, don't take it to heart we do welcome > contributions, as the language is growing we are learning as well on how to > manage our time. We might as well through an issue template as well > ## Issues > > We will not ask you to fill a dreaded form before reporting an issue. However > it is crucial that we get steps to reproduce your issue. The best would be a > minimal test that only uses Nim and the standard library. This way we can > integrate it to Nim test suite and ensures that no regressions occur in the > future.
Re: [poll] Moving all RFCs in a separate repo
-1| ---|--- Don't introduce unnecessary bureaucracy, just use labels and filters. Random idea: add label "random idea".
Re: [poll] Moving all RFCs in a separate repo
+1 for labels rather than alternate repos (or more labels such as "random idea" or "half-baked" or such). But, also +1 if Nim core devs want to aggressively close issues that are too incomplete to be a "real" RFC or are considered settled questions.
Re: [poll] Moving all RFCs in a separate repo
+1 I kinda agree with @dom96 , but I don't think we should just forget for the existing RFC-s. Instead I suggest to leave the one-s that are already detailed enough (because their author already did a good job and as an example for new RFC-s) and for the other one-s: * ask the author to expand/formalize the RFC and repost it * or directly close it only if it's no longer relevant
Re: [poll] Moving all RFCs in a separate repo
+1, but don't transfer issues to the new repo(!). The reason for a separate repo is to increase the barrier to entry for RFCs, we are overwhelmed by the number of RFCs and a lot of them are just random ideas that people come up with and not think through (sorry, but it's the harsh truth). The RFC repo should specify a formal template of how an RFC should be described and everyone should stick to it. This will ensure that: * **There is less room for ambiguity in the proposals.** This will make it easier to implement RFCs without having to go through yet even more discussions about what an RFC is really about. * **RFCs are only written for proposals which are important enough to warrant time spent writing the RFC**. This should increase their quality and make it more likely that they will be implemented. So please, just close the RFC issues and ask people to write a formal RFC if they are really passionate about their proposal.
Re: Gui Library is progressing - Windows only
First of all, how does this differ from existing Nim GUI libraries like
[NiGui](https://github.com/trustable-code/NiGui),
[ui](https://github.com/nim-lang/ui), [nimx](https://github.com/yglukhov/nimx)
(cross-platform), or more comparably [wNim](https://github.com/khchen/wNim)
(Windows only)? *
Looking at the API - it doesn't feel like very idiomatic Nim to me, yet.
1\. Procs like `CreateButton`, `NewColor`, and `AddHandler` should be in
camelCase to avoid confusion with types which are in PascalCase.
2\. I'd also get rid of all the `Create{Button,Calendar,RichEdit}` procs in
favor of a generic `Create` proc where the first argument is a `Control`.
3\. `CreateButton` doesn't seem to be actually creating the button, since I
think that's done earlier by `var b1 = Button()`, so maybe it should be called
`RenderButton` or just `render` following my last point.
> And then i will post the full code. Before that, i would like to learn how
> people are using github and publish their code via github.
I honestly recommend just putting this in a repo on GitHub and working on it in
the open, even if it's a WIP. That way people can come across it, contribute,
and see the history of changes you've made and maybe understand why.
> And i also want to learn how to use nimble to deploy my library.
This part's fairly simple thanks to Nimble's CLI but handling binaries and
configs with UI libraries can get tricky.
\---
* The main reason I ask is: If this is a project you're using to learn and all,
that's totally cool. But there's already a lot out there for GUI projects (I
haven't listed them all) and we seem to be stalling at certain points on a lot
them rather than pushing a couple implementations to a high standard.
For example `NiGui` is great but missing a lot of widgets and PRs were left to
rot. `ui` has a lot of widgets and is cross-platform but can be scratchy to
build (I had/have a lot of trouble on Windows). `wNim` is spectacular but it's
Windows only. All this being said, don't let me kill your vibe as far as
working on this goes!
Re: [poll] Moving all RFCs in a separate repo
-1, I think in the main repo they get more attention.|
Re: [poll] Moving all RFCs in a separate repo
I posted this issue at the same time, thx for pointing out you wrote this post; here's my full rebuttal with argumentation: [https://github.com/nim-lang/Nim/issues/9378](https://github.com/nim-lang/Nim/issues/9378) rfcs repo is a bad idea
[poll] Moving all RFCs in a separate repo
There was an idea by @araq to move all (future) RFC-labeled issues to their own repo. But the problem is: what to do with the current issues? (You cannot just move issues from one repo to another) Fortunately, we found a script which helps with transferring the existing issues to a new repo. You can see the results of that script in the new [rfcs repo](https://github.com/nim-lang/rfcs). There are several pros and cons of this approach: * pros * we now have a repo for all the proposals in one place — both past and future ones * the original issues are linked and easily reachable * all the existing comments are here * all the labels are preserved * cons * the existing reactions (up- and down-votes) are missing * i'm the author of all the previous issues and comments (but every issue and comment clearly states the original author) * the original authors cannot modify "my" issues (this can be remedied by writing a new comment or opening a new issue, which can then close the existing/transferred one) If this idea is accepted, we could close all RFC-labeled issues in the Nim main repo, making it the place to discuss _real issues_. * * * The reason why I'm posting this is because @araq asked me to to create a poll for this, to see the reactions. If you like the proposal, please click 'like' or write "+1", "yay" or something that is clear that you are for this. If you are against it, please write "-1", "nay", etc. and please explain why and/or offer a better/easier solution.
GUI Testing for Winim
What facilities are available in nim for automated testing of a GU interface - particularly for an app using oldwinapi or winim? Some savants advise unit testing on the non GUI parts - okay, but that misses the point. What would be nice is a facility which can alternately log out an actual window structure to a text log file or read in a previously logged file and compare it with that structure. This should be interspersed with "robot" commands to exercise the GUI. That way a human can manually run through a test by hand just once (logging out the results) and then thereafter do automated regression testing against the log file. Granted that os handles are subject to change between executions - but they could be replaced by order-of-appearance symbols in the log output - e.g. #1, #2, #3, etc. Something like this should be possible - using win32 EnumerateWindows & FindWindow etc. But I would hate to reinvent the wheel.
Re: how to increase velocity for merging PRs?
I really don't like templates that ask for too much. Just ask what you're expecting but don't go all in on formatting, we shouldn't treat everyone like kids.
Re: Gui Library is progressing - Windows only
GuiLib is just a file with some import and export commands. I divided my code into modules. So there are 14 modules now. I will sure upload those files but now i posted this code sample because i want to hear from experts that do i need to improve anything as per this sample code. If this style is simple and elegent, then i have a few works to be done. And then i will post the full code. Before that, i would like to learn how people are using github and publish their code via github. And i also want to learn how to use nimble to deploy my library.
Re: how to increase velocity for merging PRs?
+1 A practical incentive is better than making it mandatory. The template should also contain a code template for a test showing the expected result config (the discarded raw string header, btw.: is that thing documented somewhere?). PR submitters know about this, people who only report issues probably don't.
Re: how to increase velocity for merging PRs?
> We can add a Github issue template +1 This should standardize what a good issue looks like (e.g. the code that fails, its output, the expected output, etc.) and it will make it easier to reproduce, test, and finally fix it.
Re: how to increase velocity for merging PRs?
I've been thinking of moving the RFCs into their own repository, that would also clean up the issue tracker.
Re: Gui Library is progressing - Windows only
You should link the `GuiLib` btw.
Re: how to increase velocity for merging PRs?
I think that the large majority of issues currently have a minimal test case. We can add a Github issue template that basically says: If you can create a minimal test case of your issue only using Nim and its standard library, it will ensure that your issue can be treated faster and your issue will be included to the test suite to prevent potential regressions in the future. Run
Re: how to increase velocity for merging PRs?
> My quick exploration has showed that there are many older issues which were > fixed in the mean time, but the issue remained open ... There are a number of tests for specific issue numbers in Nim/tests to prove that an issue was resolved and to guard against regressions. Would it make sense to make such a test mandatory for reporting technical issues? They could get their own issues directory where all tests are expected to fail. Solved issues would become visible by their "test" failing to fail, they would then be moved to Nim/tests. Upside: issue reporters would have to provide technically valid demo code which would become a regression guard later. Downside: a higher threshold for reporting issues.
Gui Library is progressing - Windows only
Hi all, For the laast few weeks, i was trying to learn nim with little project.
A GUI library for windows is my project. Not fully finished yet, but i think if
i show it you guys, i can improve it more. So for your criticism, i am posting
a sample here. Please take a look .
import GuiLib # My Gui Library header file. It contains all necessary
module imports.
# This Application class will do the initial jobs such as getting the
hInstance.
# You can pass a string for your window class name. It's optional.
var app = Application("Window-Nim")
# Forward declarations. When will nim avoid the need for forward
declaration ?
proc OnFormCreate( e : eventArgs)
proc OnLoad( e : eventArgs)
proc OnNCCreate(e : eventArgs)
proc OnButtonClick( e : eventArgs)
proc OnButtonClick2( e : eventArgs)
proc b1OnMouseEnter( e : eventArgs)
proc OnClosing( e : eventArgs)
proc OnSetFocus( e : eventArgs)
proc OnKillFocus( e : eventArgs)
proc OnMouseLeave_cbt(e : eventArgs)
proc OnMouseMove_Cal(e : eventArgs)
proc OnClick_CustomBTN(e : eventArgs)
# Creating an instance of a form class. We need to pass the Application
object as parameter--
# -- in order to get the hInstance and other stuff.
var Form1 = NewForm(app)
# RegisterMsg is for handling wm_create msg. I can't find a better way to
do this.
Form1.RegisterMsg(WM_CREATE, OnFormCreate)
# Now we are creating the form. If you want to set the form properties, you
can--
# --set it like this.
# Form1.posx = 150
# Form1.posy = 200
# Form1.width = 800
# Form1.height = 600
# Form1.text = "My Nim Window"
# But i am using default values here.
Form1.CreateForm()
# Create some control classes
var
b1, b2 = Button()
lv = ListView()
cal = Calendar()
ud = UpDown()
dtp = DateTimePicker()
trb = TrackBar()
red = RichEdit()
cbt = CustomButton()
# Here you can add handler functions to control events lile click, mouse
move etc.
b1.AddHandler(b1.event.click, OnButtonClick)
b2.AddHandler(b2.event.click, OnButtonClick2)
b2.AddHandler(b2.event.mouseLeave, b2_OnMouseLeave)
b1.AddHandler(b1.event.mouseEnter, b1OnMouseEnter)
Form1.AddHandler(Form1.event.mouseRightUp, OnDblClk_Form1)
Form1.AddHandler(Form1.event.closing, OnClosing)
Form1.AddHandler(Form1.event.load, OnLoad)
Form1.AddHandler(Form1.event.setFocus, OnSetFocus)
Form1.AddHandler(Form1.event.killFocus, OnKillFocus)
cal.AddHandler(cal.event.mouseEnter, OnMouseMove_Cal)
red.AddHandler(red.event.mouseLeave, OnMouseLeave_Red)
cal.AddHandler(cal.event.mouseHover,OnMouseHover_Cal)
cbt.AddHandler(cbt.event.click, OnClick_CustomBTN)
cbt.AddHandler(cbt.event.mouseLeave, OnMouseLeave_cbt)
# Now, we can set the control properties.
b2.posx =140
b2.posy = 10
b2.text = "My Button"
b2.width = 150
b2.font.name = "Calibri"# Tahoma is default
b2.font.size = 12
lv.posx = 350
lv.posy = 10
lv.width = 300
cal.posx = 350
cal.posy = 10
ud.posx = 350
ud.posy = 320
# See, custom button class has so many color properties.
cbt.posx= 350
cbt.posy= 220
cbt.text = "Owner Drawn BTN"
cbt.backColor = NewColor(80, 16, 44)# NewColor function receives RGB
values and returns a COLORREFF
cbt.foreColor = NewColor(15, 15, 80)
cbt.hoverBackColor = cbt.backColor
cbt.hoverForeColor = NewColor(238,20,49)
cbt.width = 200
cbt.height = 80
dtp.posx = 150
dtp.posy = 150
trb.posx = 150
trb.posy = 120
red.posx = 10
red.posy = 200
# Now we can create our controls.
b1.CreateButton()
b2.CreateButton()
cal.CreateCalendar()
ud.CreateUpDown()
dtp.CreateDateTimePicker()
trb.CreateTrackBar()
red.CreateRichEdit()
cbt.CreateCustomButton()
# Let's display our form
Form1.ShowForm()
# This is the main loop.
app.Run()
# Now, these are the event handler function area.
# Argument "e" is a structure. It contains all necessary elements to handle
the--
# --WndProc function
proc OnCreate( e : eventArgs) =
echo "Window created."
echo e.handle # e.handle is the window HWND
proc OnLoad( e : eventArgs) =
echo "Window Loaded"
proc OnButtonClick( e : eventArgs) =
b2.text = "Changed Text"
proc OnButtonClick2( e : eventArgs) =
msgBox("A Message")
proc b1OnMouseEnter( e : eventArgs) =
echo "Mouse entered on button 1"
proc b2_OnMouseLeave( e : eventArgs) =
echo "Mouse leaved from Button 2"
proc OnNCCreate( e : eventArgs) =
echo "NC CREATE handled"
proc OnClosing( e : eventArgs) =
echo "Form is closing.
