Hi Steve, After looking at git-svn related info online, I have used svnsync to duplicate the remote repo locally. Not sure of how the syncing will work in future, when I have made local changes in this local repo, either way that is for another day.
On Fri, Dec 6, 2024 at 2:18 PM C Hanish Menon <hanish...@gmail.com> wrote: > > Hi Steve, > > I havent used svn much in life, use git mostly when required. Last > time was like 2 decades back or so. > > I tried using svnadmin create to create a local repository > > and in turn use svn import to import upstream scidvspc into that local > repository, but it fails with > > "svn: E175013: Access to '/p/scidvspc/code/!svn/me' forbidden" > > The command I used, along with some options which I used without rtfm was > > svn import --force --no-auth-cache code > http://svn.code.sf.net/p/scidvspc/code -m "Create a local repo of > scidvspc upstream" > > The idea being to create a local repository decoupled from the > upstream, so that I can do my own experiments if required without > needing any permissions in the upstream repository, while at the same > time, if possible have a structured and ready way of importing/syncing > with upstream, if required even in future without losing any local > experiments, like with git clone/pull. But given that the above fails, > not able to work with svn. Do you have any pointers for how to go > abhout. > > On Fri, Dec 6, 2024 at 2:42 AM Steve A <stevena...@gmail.com> wrote: > > > > If you edit individual files, and send the "svn diff", would be better. > > Cheers > > > > On Friday, December 6, 2024, Steve A <stevena...@gmail.com> wrote: > >> > >> > makes the text and arrow disappear, when > >> working with a single pv from analysis engine, bcas many a times when > >> the engine is generating the next depth pv, it will generate in > >> between move lines which are very short and so useless, so also I dont > >> call boardVisualiseMoves in these cases, > >> > >> Ok, thanks for explaining this. I was a bit heavy handed here... I'm busy > >> through the week... and will look at it properly on the weekend. > >> > >> Regards. > >> > >> On Friday, December 6, 2024, C Hanish Menon <hanish...@gmail.com> wrote: > >>> > >>> Hi Steve, > >>> > >>> I notice that you have reverted/changed certain aspects of my original > >>> patch. I have put the reasoning for my original flow below, and the > >>> issues of reverting/changing them > >>> > >>> 1) I am attaching an image of what I meant earlier wrt issue with > >>> placing move number in the middle of the line, and this is a simple > >>> case. There can be more complex cases where the center point will not > >>> match 0,0 wrt diff in center points, but still will have the text > >>> overlapping, so one will have to account for used font's max > >>> top-bottom and left-right boundaries wrt chars, leading to more > >>> complex mechanism to try and avoid these. While placing the number on > >>> the landing square center will make avoiding this overlapping simple > >>> and straightforward. > >>> > >>> 2) Using global(ie used in other places also) var tag, instead of tags > >>> local to boardVisualiseMoves, makes the text and arrow disappear, when > >>> working with a single pv from analysis engine, bcas many a times when > >>> the engine is generating the next depth pv, it will generate in > >>> between move lines which are very short and so useless, so also I dont > >>> call boardVisualiseMoves in these cases, so that the board can show > >>> the previous depth full move line's initial part, while the engine is > >>> building up the next depth move line. In these cases, with this > >>> modified flow, the text and arrow will disappear. > >>> > >>> 3) Using only black instead of a text color with contrasting shadow > >>> color, makes the move number non discernable in many cases. > >>> > >>> By any chance, did you want me to send you the patch (mapped to the > >>> individual tcl dir files, instead of my original applied to scid final > >>> script) after updating them to include my original logics? > >>> > >>> Also I had a look at the change you have done to the > >>> Tools->AnalysisEngine dialog, they definitely are better and make > >>> things clearer compared to previous flow. And for the case which I had > >>> mentioned in my last email, I can always potentially add a > >>> arrow+sequential entry to that drop down list, and use seperate if > >>> conditions rather than the if-else flow in your patch > >>> > >>> > >>> On Thu, Dec 5, 2024 at 6:22 PM C Hanish Menon <hanish...@gmail.com> wrote: > >>> > > >>> > Hi Steve, > >>> > > >>> > One among a few other reasons also, to directly use create line / > >>> > arrow in boardVisualiseMove was to keep the line thin and also non > >>> > interactive, so that it can overlap with the existing 1st move arrows. > >>> > But no issues, I will have a look at the program with your updated > >>> > diff. > >>> > > >>> > And given that it is open source, I can always change, in case, if I > >>> > want a different flow ;) > >>> > > >>> > On Thu, Dec 5, 2024 at 5:19 PM Steve A <stevena...@gmail.com> wrote: > >>> > > > >>> > > Yeah, *sorry* Hanish but I have made quite some changes to your code. > >>> > > I find having both sets of arrows at the same time redundant and > >>> > > distracting. And my version is much more attractive imho. > >>> > > > >>> > > If you look at the tools->analysis widget, you'll see what I've done. > >>> > > Middle clicking the board will toggle views (I hope). > >>> > > > >>> > > Regards, S. > >>> > > > >>> > > On Thursday, December 5, 2024, C Hanish Menon <hanish...@gmail.com> > >>> > > wrote: > >>> > >> > >>> > >> Hi Steve, > >>> > >> > >>> > >> Have a query. Looking at the diff which you sent (initial glance of > >>> > >> the code), it appears like you have changed the overall flow so that > >>> > >> the analysis board either > >>> > >> > >>> > >> a) shows the 1st move of each move line in multipv (the existing > >>> > >> flow/feature in scidvspc) or > >>> > >> b) the visualisation of initial few moves from the main pv from among > >>> > >> the multipv (the additional flow/feature which I had added). > >>> > >> > >>> > >> and not both at the same time. > >>> > >> > >>> > >> But dont you think from a user perspective, being able to see both > >>> > >> parallely on the analysis board is a better flow, like what I had set > >>> > >> up originally. Because both give different yet useful info, that one > >>> > >> will be interested in knowing when analysing a game at the same time. > >>> > >> Additionally it also has the advantage of keeping the changes to the > >>> > >> existing flow very minimal. > >>> > >> > >>> > >> I feel ideally we shouldnt limit the user to select between both, > >>> > >> bcas > >>> > >> both can be used/viewed parallely, without affecting one another, and > >>> > >> provide different useful info to the user. So rather I am not > >>> > >> modifying the diff you sent, instead I am attaching the additional > >>> > >> patch to force mainpv analysis board visualisation update, if a > >>> > >> deeper > >>> > >> probe leads to a shorter move line, wrt the original patch which I > >>> > >> had > >>> > >> sent. > >>> > >> > >>> > >> On Thu, Dec 5, 2024 at 3:40 PM C Hanish Menon <hanish...@gmail.com> > >>> > >> wrote: > >>> > >> > > >>> > >> > Also, the reason why I didnt use the mid of the arrow to place the > >>> > >> > move number is because, if there are too many crossing moves, then > >>> > >> > the > >>> > >> > text may overlap, and trying to avoid that overlap will be bit more > >>> > >> > complicated, than if we are working with landing square center > >>> > >> > kind of > >>> > >> > flow. > >>> > >> > > >>> > >> > On Thu, Dec 5, 2024 at 3:37 PM C Hanish Menon > >>> > >> > <hanish...@gmail.com> wrote: > >>> > >> > > > >>> > >> > > Hi Steve, > >>> > >> > > > >>> > >> > > To avoid updating partial moves from the next depth, I have a > >>> > >> > > check, > >>> > >> > > that is what stops updating the board on mate or draw kind of > >>> > >> > > situations, when the move length returned at a higher depth may > >>> > >> > > be > >>> > >> > > shorter, I have modified the logic with a seen depth tracking to > >>> > >> > > ensure that if two subsequent depths return a shorter move line, > >>> > >> > > then > >>> > >> > > it will update the visualisation with the shorter move line. > >>> > >> > > > >>> > >> > > Will send you the patch in some time. > >>> > >> > > > >>> > >> > > On Thu, Dec 5, 2024 at 2:27 PM Steve A <stevena...@gmail.com> > >>> > >> > > wrote: > >>> > >> > > > > >>> > >> > > > Sorry to spam you.... but there might be a bug in your code > >>> > >> > > > when we reach mate too, > >>> > >> > > > (where i had introduced a bug, fixed in this version). > >>> > >> > > > Thats it for another day , Cheers, S.A. > >>> > >> > > > > >>> > >> > > > > >>> > >> > > > On Thu, Dec 5, 2024 at 5:06 PM Steve A <stevena...@gmail.com> > >>> > >> > > > wrote: > >>> > >> > > >> > >>> > >> > > >> Hi Hanish > >>> > >> > > >> Ok, We should be able to include this feature :) > >>> > >> > > >> Attached is my alpha version... could you please update to > >>> > >> > > >> subversion, then apply this patch? > >>> > >> > > >> > >>> > >> > > >> The only thing i don't really like at the moment is having > >>> > >> > > >> the extra spinbox in the engine toolbar... > >>> > >> > > >> Might change this down the road. > >>> > >> > > >> Thanks, Steven > >>> > >> > > >> > >>> > >> > > >> On Thu, Dec 5, 2024 at 3:05 PM Steve A <stevena...@gmail.com> > >>> > >> > > >> wrote: > >>> > >> > > >>> > >>> > >> > > >>> ok... I'm onto it now. I see your not using drawArrow > >>> > >> > > >>> > >>> > >> > > >>> On Thu, Dec 5, 2024 at 11:01 AM Steve A > >>> > >> > > >>> <stevena...@gmail.com> wrote: > >>> > >> > > >>>> > >>> > >> > > >>>> Otherwise, I'll do it sometime. Cheers > >>> > >> > > >>>> > >>> > >> > > >>>> On Thursday, December 5, 2024, C Hanish Menon > >>> > >> > > >>>> <hanish...@gmail.com> wrote: > >>> > >> > > >>>>> > >>> > >> > > >>>>> Hi Steve, > >>> > >> > > >>>>> > >>> > >> > > >>>>> Thanks for the feedback and thoughts. > >>> > >> > > >>>>> > >>> > >> > > >>>>> Attaching the updated patch where > >>> > >> > > >>>>> > >>> > >> > > >>>>> 1. moved the visualisation of moves into a generic > >>> > >> > > >>>>> function of its > >>> > >> > > >>>>> own, which inturn is called from updateAnalysisBoard > >>> > >> > > >>>>> function to show > >>> > >> > > >>>>> the analysis engine's main pv's initial moves > >>> > >> > > >>>>> > >>> > >> > > >>>>> 1.1. using the board argument passed to this, one can make > >>> > >> > > >>>>> the move > >>> > >> > > >>>>> visualisation to appear on the main board or any other > >>> > >> > > >>>>> board, if one > >>> > >> > > >>>>> wants to. The n argument will also need to be unique for > >>> > >> > > >>>>> each of a > >>> > >> > > >>>>> different board. > >>> > >> > > >>>>> > >>> > >> > > >>>>> 1.2. if in any other place one wants to visualise a > >>> > >> > > >>>>> sequence of moves, > >>> > >> > > >>>>> the function can be called to achieve the same and inturn > >>> > >> > > >>>>> on whichever > >>> > >> > > >>>>> board that one may want to in that context. > >>> > >> > > >>>>> > >>> > >> > > >>>>> 2. the move number text shown on the board's squares uses > >>> > >> > > >>>>> contrasting > >>> > >> > > >>>>> shadow color to try and ensure that irrespective of light > >>> > >> > > >>>>> or dark > >>> > >> > > >>>>> square and or pieces, the numbers can be potentially > >>> > >> > > >>>>> visible to an > >>> > >> > > >>>>> extent. > >>> > >> > > >>>>> > >>> > >> > > >>>>> 3. If multiple moves in the move list land on the same > >>> > >> > > >>>>> square, the > >>> > >> > > >>>>> move numbers are prepended and shown on the square. > >>> > >> > > >>>>> > >>> > >> > > >>>>> 4. bcas text creation is now handled within the move > >>> > >> > > >>>>> visualisation > >>> > >> > > >>>>> function using its own tags, the text will be retained on > >>> > >> > > >>>>> the board to > >>> > >> > > >>>>> a great extent, even when some other logic may update the > >>> > >> > > >>>>> board, if > >>> > >> > > >>>>> required. > >>> > >> > > >>>>> > >>> > >> > > >>>>> This functionality can indirectly allow users to visualise > >>> > >> > > >>>>> to an > >>> > >> > > >>>>> extent where the pieces will be after a few moves > >>> > >> > > >>>>> (currently spinbox > >>> > >> > > >>>>> limited to 8 moves), to an extent, while also seeing how > >>> > >> > > >>>>> the pieces > >>> > >> > > >>>>> reached there. > >>> > >> > > >>>>> > >>> > >> > > >>>>> Not sure if varying the shades of the arrow as one > >>> > >> > > >>>>> proceeds through > >>> > >> > > >>>>> the moves in the moves list can allow a lot more of the > >>> > >> > > >>>>> sequence of > >>> > >> > > >>>>> moves to be inferred/shown because of dependencies like > >>> > >> > > >>>>> users > >>> > >> > > >>>>> monitor's brightness and contrast settings, as well as > >>> > >> > > >>>>> possible board > >>> > >> > > >>>>> square colors and so impacting visuals. However because the > >>> > >> > > >>>>> visualisation of moves logic has been moved into a func of > >>> > >> > > >>>>> its own, > >>> > >> > > >>>>> changing the logic in this single location should allow > >>> > >> > > >>>>> the benefits > >>> > >> > > >>>>> of any changes to be visible wherever the moves > >>> > >> > > >>>>> visualization function > >>> > >> > > >>>>> may be used. > >>> > >> > > >>>>> > >>> > >> > > >>>>> > >>> > >> > > >>>>> > >>> > >> > > >>>>> On Wed, Dec 4, 2024 at 4:46 PM Steve A > >>> > >> > > >>>>> <stevena...@gmail.com> wrote: > >>> > >> > > >>>>> > > >>> > >> > > >>>>> > The original anal board view showed the end position > >>> > >> > > >>>>> > after the whole pv was moved. I wonder if it would be > >>> > >> > > >>>>> > desirable to limit how many moves we see. > >>> > >> > > >>>>> > > >>> > >> > > >>>>> > But i'm thinking we should be making more use of the > >>> > >> > > >>>>> > arrow colors. > >>> > >> > > >>>>> > Mainly, i think we should be able to colour the main PV > >>> > >> > > >>>>> > black, then lighten up the other PV arrows , perhaps in > >>> > >> > > >>>>> > accordance to their score... Might be harder to code > >>> > >> > > >>>>> > though. I'll try to look at it on the weekend > >>> > >> > > >>>>> > eg set color [gradient $::defaultForeground .6 .] > >>> > >> > > >>>>> > > >>> > >> > > >>>>> > cheers > >>> > >> > > >>>>> > > >>> > >> > > >>>>> > > >>> > >> > > >>>>> > On Wednesday, December 4, 2024, Steve A > >>> > >> > > >>>>> > <stevena...@gmail.com> wrote: > >>> > >> > > >>>>> >> > >>> > >> > > >>>>> >> It's a nice idea, just that practical issues limit its > >>> > >> > > >>>>> >> clarity. Please send me your revisions and I'll see if > >>> > >> > > >>>>> >> I can contribute to it. > >>> > >> > > >>>>> >> Cheers > >>> > >> > > >>>>> >> > >>> > >> > > >>>>> >> On Wednesday, December 4, 2024, C Hanish Menon > >>> > >> > > >>>>> >> <hanish...@gmail.com> wrote: > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> Hi Steve, > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> The idea behind my patch was to try and visualise the > >>> > >> > > >>>>> >>> initial few > >>> > >> > > >>>>> >>> moves of the 1st/main pv in a single/multipv response > >>> > >> > > >>>>> >>> from the engine. > >>> > >> > > >>>>> >>> And the reason was to try and make it easier to get a > >>> > >> > > >>>>> >>> feel of the > >>> > >> > > >>>>> >>> chain (or otherwise) of moves that the engine may be > >>> > >> > > >>>>> >>> suggesting/looking-at in an easy implicit way, without > >>> > >> > > >>>>> >>> having to do > >>> > >> > > >>>>> >>> any end user driven actions on the gui (like using +v > >>> > >> > > >>>>> >>> (with or without > >>> > >> > > >>>>> >>> trial mode) and in turn looking at the moves in detail > >>> > >> > > >>>>> >>> on the main > >>> > >> > > >>>>> >>> board, by navigating through the moves). > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> Also given that one may want to run different engines > >>> > >> > > >>>>> >>> parallely at the > >>> > >> > > >>>>> >>> same time, it makes more sense to visualise the engine > >>> > >> > > >>>>> >>> moves on the > >>> > >> > > >>>>> >>> respective local analysis board, rather than the main > >>> > >> > > >>>>> >>> board. This also > >>> > >> > > >>>>> >>> avoids the additional decision that needs to be made > >>> > >> > > >>>>> >>> otherwise of > >>> > >> > > >>>>> >>> which of the engine's main pv to show on the main > >>> > >> > > >>>>> >>> board, if the main > >>> > >> > > >>>>> >>> board were to be used. While parallely giving the > >>> > >> > > >>>>> >>> flexibility of > >>> > >> > > >>>>> >>> viewing main pv of multiple engines parallely in their > >>> > >> > > >>>>> >>> separate > >>> > >> > > >>>>> >>> analysis boards. > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> Also keeping the logic to be a simple visualisation > >>> > >> > > >>>>> >>> and not > >>> > >> > > >>>>> >>> interaction with the corresponding visualisation, > >>> > >> > > >>>>> >>> ensures that the > >>> > >> > > >>>>> >>> already existing logic of showing the 1st move of the > >>> > >> > > >>>>> >>> different > >>> > >> > > >>>>> >>> multiple pv's that the engine generates on the > >>> > >> > > >>>>> >>> analysis board and in > >>> > >> > > >>>>> >>> turn clicking it to use as the move on the main board, > >>> > >> > > >>>>> >>> doesnt get > >>> > >> > > >>>>> >>> affected/overloaded in any way. Nor needed given that > >>> > >> > > >>>>> >>> the idea was to > >>> > >> > > >>>>> >>> visualise the initial few moves in the engine's main > >>> > >> > > >>>>> >>> pv (among > >>> > >> > > >>>>> >>> single/multipv). > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> Also at a different level, not sure why, but I am not > >>> > >> > > >>>>> >>> seeing the 1st > >>> > >> > > >>>>> >>> move each of the different multipv's generated by the > >>> > >> > > >>>>> >>> analysis engine, > >>> > >> > > >>>>> >>> on the main board, after enabling show arrows in > >>> > >> > > >>>>> >>> Tools->AnalysisEngine. > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> PS: I am refining my patch further like using shadow > >>> > >> > > >>>>> >>> colors to make > >>> > >> > > >>>>> >>> the text more visible irrespective of underlying > >>> > >> > > >>>>> >>> square or piece is > >>> > >> > > >>>>> >>> light or dark; look at using dict to allow showing > >>> > >> > > >>>>> >>> move numbers of > >>> > >> > > >>>>> >>> multiple moves landing on same square; try ensure that > >>> > >> > > >>>>> >>> move numbers > >>> > >> > > >>>>> >>> remain on screen, even when engine is in the middle of > >>> > >> > > >>>>> >>> building up the > >>> > >> > > >>>>> >>> next deeper level pv (rather I had purposefully not > >>> > >> > > >>>>> >>> looked at adding > >>> > >> > > >>>>> >>> support for that to act as a indication that what is > >>> > >> > > >>>>> >>> being visualised > >>> > >> > > >>>>> >>> in not the latest one, but the previous one, bcas > >>> > >> > > >>>>> >>> engine is still in > >>> > >> > > >>>>> >>> middle of building the current deeper pv; however when > >>> > >> > > >>>>> >>> switching > >>> > >> > > >>>>> >>> between different engine tabs, it is not practical to > >>> > >> > > >>>>> >>> try remember the > >>> > >> > > >>>>> >>> not shown move numbers). I may be done with these > >>> > >> > > >>>>> >>> changes in a day or > >>> > >> > > >>>>> >>> two, depending on as and when I can steal time to work > >>> > >> > > >>>>> >>> on this. > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> On Tue, Dec 3, 2024 at 4:32 PM Steve A > >>> > >> > > >>>>> >>> <stevena...@gmail.com> wrote: > >>> > >> > > >>>>> >>> > > >>> > >> > > >>>>> >>> > Hmmm - it's interesting , but pretty raw and not > >>> > >> > > >>>>> >>> > something i'd use. But cheers. > >>> > >> > > >>>>> >>> > > >>> > >> > > >>>>> >>> > I thought for a second you were making a patch to > >>> > >> > > >>>>> >>> > draw the engine arrows on the main board, which lots > >>> > >> > > >>>>> >>> > of GUIs do already. > >>> > >> > > >>>>> >>> > This is also something i'm not too especially keen > >>> > >> > > >>>>> >>> > on because we have arrows everywhere already! :) And > >>> > >> > > >>>>> >>> > it presents lots of unresolved issues. > >>> > >> > > >>>>> >>> > .... But, since i *do* already have a quick patch > >>> > >> > > >>>>> >>> > that does this, I thought to add it to svn (which > >>> > >> > > >>>>> >>> > i've done just now, and also attached below). > >>> > >> > > >>>>> >>> > To see the arrows, you''ll have to select "Show > >>> > >> > > >>>>> >>> > Arrows" in Tools->AnalysisEngines. > >>> > >> > > >>>>> >>> > Cheers, S.A. > >>> > >> > > >>>>> >>> > > >>> > >> > > >>>>> >>> > On Tue, Dec 3, 2024 at 7:22 AM C Hanish Menon > >>> > >> > > >>>>> >>> > <hanish...@gmail.com> wrote: > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> Hi Steve, > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> I have tried adding support for simple visualising > >>> > >> > > >>>>> >>> >> of the main pv > >>> > >> > > >>>>> >>> >> generated by uci engine on the analysis board. The > >>> > >> > > >>>>> >>> >> user can control > >>> > >> > > >>>>> >>> >> how many moves ahead to show on the board, using a > >>> > >> > > >>>>> >>> >> spinbox I have > >>> > >> > > >>>>> >>> >> added next to the show analysis board > >>> > >> > > >>>>> >>> >> checkbox/button. > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> I am attaching the patch with the email and a > >>> > >> > > >>>>> >>> >> sample image of how it appears. > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> NOTE: I have patched the scid file directly. I am > >>> > >> > > >>>>> >>> >> not a tcl/tk > >>> > >> > > >>>>> >>> >> programmer, I have looked at the code in scid and > >>> > >> > > >>>>> >>> >> tried to > >>> > >> > > >>>>> >>> >> structure/implement the patch to get the job done. > >>> > >> > > >>>>> >>> >> There is a small > >>> > >> > > >>>>> >>> >> probability that I may not be doing things the > >>> > >> > > >>>>> >>> >> tcltk way. > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> On Sat, Nov 30, 2024 at 6:58 PM C Hanish Menon > >>> > >> > > >>>>> >>> >> <hanish...@gmail.com> wrote: > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > Hi Steve, > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > Thanks for adapting and incorporating the patches. > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > Regarding snap, I dont think I have currently set > >>> > >> > > >>>>> >>> >> > %F, it's been a long > >>> > >> > > >>>>> >>> >> > time, I normally start from the command line. > >>> > >> > > >>>>> >>> >> > However it is a good > >>> > >> > > >>>>> >>> >> > input, which can be useful for many, will update > >>> > >> > > >>>>> >>> >> > it. > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > Previously in the snapcraft.yaml file, which I am > >>> > >> > > >>>>> >>> >> > also bundling with > >>> > >> > > >>>>> >>> >> > snap, I was fetching the latest svn commit and > >>> > >> > > >>>>> >>> >> > creating a snap of it, > >>> > >> > > >>>>> >>> >> > so that anyone attempting to create snap on their > >>> > >> > > >>>>> >>> >> > own can get the > >>> > >> > > >>>>> >>> >> > latest svn commit based version. But with the new > >>> > >> > > >>>>> >>> >> > version of snapcraft > >>> > >> > > >>>>> >>> >> > (used to create snap), they seem to have > >>> > >> > > >>>>> >>> >> > removed/goofed up the svn > >>> > >> > > >>>>> >>> >> > fetch logic, so I am using the tar file of the > >>> > >> > > >>>>> >>> >> > scidvspc release. Need > >>> > >> > > >>>>> >>> >> > to check, how to patch in svn fetching again wrt > >>> > >> > > >>>>> >>> >> > snapcraft may be by > >>> > >> > > >>>>> >>> >> > overriding its default fetch flow, so that people > >>> > >> > > >>>>> >>> >> > can create snap > >>> > >> > > >>>>> >>> >> > using the latest commit, if possible. > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > Given that you would be familiar with sourceforge > >>> > >> > > >>>>> >>> >> > and its svn, by any > >>> > >> > > >>>>> >>> >> > chance, do you know, if there is a standard url > >>> > >> > > >>>>> >>> >> > one could try to fetch > >>> > >> > > >>>>> >>> >> > to get an archive / tar of the latest svn commit > >>> > >> > > >>>>> >>> >> > of a project hosted > >>> > >> > > >>>>> >>> >> > on sourceforge svn. > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > On Sat, Nov 30, 2024 at 3:13 AM Steve A > >>> > >> > > >>>>> >>> >> > <stevena...@gmail.com> wrote: > >>> > >> > > >>>>> >>> >> > > > >>> > >> > > >>>>> >>> >> > > Thanks Hanish. I've adopted or tweaked all your > >>> > >> > > >>>>> >>> >> > > changes and made a commit. (I've given the > >>> > >> > > >>>>> >>> >> > > analysis boards identical coord setup to the > >>> > >> > > >>>>> >>> >> > > main board, but making the font smaller). > >>> > >> > > >>>>> >>> >> > > https://sourceforge.net/p/scidvspc/code/3485/ > >>> > >> > > >>>>> >>> >> > > > >>> > >> > > >>>>> >>> >> > > P.S. Thanks for creating the snap package. I > >>> > >> > > >>>>> >>> >> > > think i recently had some correspondence about > >>> > >> > > >>>>> >>> >> > > it. Do you include the %F arg (or similar) in > >>> > >> > > >>>>> >>> >> > > your scidvspc.desktop file (ie "Exec=scid %F"). > >>> > >> > > >>>>> >>> >> > > This allows opening desired files. > >>> > >> > > >>>>> >>> >> > > > >>> > >> > > >>>>> >>> >> > > Regards Steven. > >>> > >> > > >>>>> >>> >> > > > >>> > >> > > >>>>> >>> >> > > On Sat, Nov 30, 2024 at 2:12 AM C Hanish Menon > >>> > >> > > >>>>> >>> >> > > <hanish...@gmail.com> wrote: > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> Hi, > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> I follow and explore chess very very > >>> > >> > > >>>>> >>> >> > >> infrequently, like once in a few > >>> > >> > > >>>>> >>> >> > >> years, usually when maybe a chess championship > >>> > >> > > >>>>> >>> >> > >> is going on or hear > >>> > >> > > >>>>> >>> >> > >> something about a new chess engine or I am > >>> > >> > > >>>>> >>> >> > >> experimenting something or > >>> > >> > > >>>>> >>> >> > >> so. > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> So also I am not good at visualizing text > >>> > >> > > >>>>> >>> >> > >> chess move lines/variations > >>> > >> > > >>>>> >>> >> > >> without having visual hint like coordinates on > >>> > >> > > >>>>> >>> >> > >> a chess board. > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> Given that currently ScidVsPC doesnt have an > >>> > >> > > >>>>> >>> >> > >> option for the same wrt > >>> > >> > > >>>>> >>> >> > >> analysis board, have created this patch (03- > >>> > >> > > >>>>> >>> >> > >> patch file name) to > >>> > >> > > >>>>> >>> >> > >> enable the same. If the user enables > >>> > >> > > >>>>> >>> >> > >> coordinates on all sides wrt the > >>> > >> > > >>>>> >>> >> > >> main board (ie boardCoords value 2), then this > >>> > >> > > >>>>> >>> >> > >> logic will enable > >>> > >> > > >>>>> >>> >> > >> coordinates on the analysis board. > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> Inturn when working on this, noticed that the > >>> > >> > > >>>>> >>> >> > >> board::flip logic wasn't > >>> > >> > > >>>>> >>> >> > >> setting the vertical (1-8) coordinate values > >>> > >> > > >>>>> >>> >> > >> correctly for the > >>> > >> > > >>>>> >>> >> > >> analysis board always, it seemed to have a > >>> > >> > > >>>>> >>> >> > >> race based on when the > >>> > >> > > >>>>> >>> >> > >> board gets enabled and when the user toggles > >>> > >> > > >>>>> >>> >> > >> board coords. So have > >>> > >> > > >>>>> >>> >> > >> created a additional patch (04- patch file > >>> > >> > > >>>>> >>> >> > >> name) which sets the labels > >>> > >> > > >>>>> >>> >> > >> based purely on flip variable. NOTE: Not able > >>> > >> > > >>>>> >>> >> > >> to reproduce this > >>> > >> > > >>>>> >>> >> > >> currently, dont remember the sequence of > >>> > >> > > >>>>> >>> >> > >> enabling different options > >>> > >> > > >>>>> >>> >> > >> and boards, but did notice it few times > >>> > >> > > >>>>> >>> >> > >> initially, when I was working > >>> > >> > > >>>>> >>> >> > >> with only 03- patch file. Also this 04- patch > >>> > >> > > >>>>> >>> >> > >> file makes the logic > >>> > >> > > >>>>> >>> >> > >> directly depend on flip variable rather than > >>> > >> > > >>>>> >>> >> > >> any value that may be > >>> > >> > > >>>>> >>> >> > >> already there wrt the labels. So feel this may > >>> > >> > > >>>>> >>> >> > >> be a better logic. > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> NOTE: I had created & inturn maintain > >>> > >> > > >>>>> >>> >> > >> scidvspc-hkvc snap package, to > >>> > >> > > >>>>> >>> >> > >> run scidvspc on linux distros with snap > >>> > >> > > >>>>> >>> >> > >> package system support, which > >>> > >> > > >>>>> >>> >> > >> again I update once in a bluemoon. These > >>> > >> > > >>>>> >>> >> > >> patches are included in the > >>> > >> > > >>>>> >>> >> > >> version which I have released there. I have > >>> > >> > > >>>>> >>> >> > >> added the suffix -hkvc to > >>> > >> > > >>>>> >>> >> > >> ensure that in future if the scidvspc team > >>> > >> > > >>>>> >>> >> > >> wants to release their own > >>> > >> > > >>>>> >>> >> > >> snap package, there is no confusion. These > >>> > >> > > >>>>> >>> >> > >> patches can be > >>> > >> > > >>>>> >>> >> > >> tested/verified by running the scidvspc-hkvc > >>> > >> > > >>>>> >>> >> > >> snap package, if needed. > >>> > >> > > >>>>> >>> >> > >> > >>> > >> > > >>>>> >>> >> > >> -- > >>> > >> > > >>>>> >>> >> > >> Keep ;-) > >>> > >> > > >>>>> >>> >> > >> HanishKVC > >>> > >> > > >>>>> >>> >> > >> _______________________________________________ > >>> > >> > > >>>>> >>> >> > >> Scidvspc-users mailing list > >>> > >> > > >>>>> >>> >> > >> Scidvspc-users@lists.sourceforge.net > >>> > >> > > >>>>> >>> >> > >> https://lists.sourceforge.net/lists/listinfo/scidvspc-users > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > > >>> > >> > > >>>>> >>> >> > -- > >>> > >> > > >>>>> >>> >> > Keep ;-) > >>> > >> > > >>>>> >>> >> > HanishKVC > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> > >>> > >> > > >>>>> >>> >> -- > >>> > >> > > >>>>> >>> >> Keep ;-) > >>> > >> > > >>>>> >>> >> HanishKVC > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> > >>> > >> > > >>>>> >>> -- > >>> > >> > > >>>>> >>> Keep ;-) > >>> > >> > > >>>>> >>> HanishKVC > >>> > >> > > >>>>> > >>> > >> > > >>>>> > >>> > >> > > >>>>> > >>> > >> > > >>>>> -- > >>> > >> > > >>>>> Keep ;-) > >>> > >> > > >>>>> HanishKVC > >>> > >> > > > >>> > >> > > > >>> > >> > > > >>> > >> > > -- > >>> > >> > > Keep ;-) > >>> > >> > > HanishKVC > >>> > >> > > >>> > >> > > >>> > >> > > >>> > >> > -- > >>> > >> > Keep ;-) > >>> > >> > HanishKVC > >>> > >> > >>> > >> > >>> > >> > >>> > >> -- > >>> > >> Keep ;-) > >>> > >> HanishKVC > >>> > > >>> > > >>> > > >>> > -- > >>> > Keep ;-) > >>> > HanishKVC > >>> > >>> > >>> > >>> -- > >>> Keep ;-) > >>> HanishKVC > > > > -- > Keep ;-) > HanishKVC -- Keep ;-) HanishKVC _______________________________________________ Scidvspc-users mailing list Scidvspc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scidvspc-users
