FLOSS Project Planets

Codementor: Python Tutorial | A Complete Guide to Learn Python Programming

Planet Python - Thu, 2019-03-07 02:47
This Python Tutorial blog will help you learn Python programming basics - Variables, Data types, Operators, Conditional Statements, Loops and Functions.
Categories: FLOSS Project Planets

codingdirectional: Is a number divisible?

Planet Python - Thu, 2019-03-07 01:06

After we have wrapped up the previous Forex project we will go easy today by solving a simple question from Codewars and then I will talk about the future plan for this website at the end of this post.

The question goes like this, we are given a number where we will need to create a method to determine whether that number is divisible by the two following numbers or not, if so then the method will return True or else it will return False.

def is_divisible(n,x,y): if(n % x == 0 and n % y == 0): return True else: return False

It is pretty much a straight forward and simple solution. Hope you like this one.

Alright, let us talk about the future of this website a little bit. After the previous project, I think I will start to create many more small scale projects in the future that will probably take a week time to finish for each one of them. The future project will not relate to the financial stuff anymore but if you want to read more projects such as the previous Forex project then I have created another new website where it will host all the python projects that are related to stock, Forex, and cryptocurrency, if you are interested in this type of project then do visit this site through this link.

So much for that, we will begin our next project in the next chapter.

Categories: FLOSS Project Planets

Russ Allbery: Net::Duo 1.02

Planet Debian - Thu, 2019-03-07 00:52

This is an alternative Perl interface to the Duo Security second-factor authentication service. This release supports the new required pagination for returning lists of users and integrations, which will take effect on March 15, 2019. It does this in the simplest way possible: just making repeated calls until it retrieves the full list.

With this release, I'm also orphaning the package. I wrote this package originally for Stanford, and had thought I'd continue to find a reason to maintain it after I left. But I'm not currently maintaining any Duo integrations that would benefit from it, and my current employer doesn't use Perl. Given that, I want to make it obvious that it's not keeping up with the current Duo API and you would be better off using the Perl code that Duo themselves provide.

That said, I think the object-oriented model this package exposes is nicer and makes for cleaner Perl code when interacting with Duo. If you agree, please feel welcome to pick up maintenance, and let me know if you want the web site redirected to its new home.

This release also updates test code, supporting files, and documentation to my current standards, since I was making a release anyway.

You can get the current release from the Net::Duo distribution page.

Categories: FLOSS Project Planets

gamingdirectional: The winning scene of the game

Planet Python - Wed, 2019-03-06 23:30

Hello and welcome back, in this article we will create the winning scene for this pygame project. Basically, we have already created those winning scene mechanisms in the last project where the game’s winning scene will pop up when the player has concurred all the levels, the player can then press on the play button to restart the game again if he wants to. Below are the three files that are...

Source

Related posts: Create enemy missiles within the Enemy object Rotate the mana object Final touch up for the boy boundary detection mechanism Moving the player object in Pygame Modify the enemy sprite’s animation Create the animation character on the maze Change the direction of the enemy ship Lets put the game instruction online instead Create the about scene for pygame project Edit the level 2 game map
Categories: FLOSS Project Planets

Dirk Eddelbuettel: RInside 0.2.15

Planet Debian - Wed, 2019-03-06 19:40

A new release 0.2.15 of RInside arrived on CRAN and in Debian today. This marks the first release in almost two years, and it brings some build enhancements. RInside provides a set of convenience classes which facilitate embedding of R inside of C++ applications and programs, using the classes and functions provided by Rcpp.

RInside is stressing the CRAN system a little in that it triggers a number of NOTE and WARNING messages. Some of these are par for the course as we get close to R internals not all of which are “officially” in the API. My continued thanks to the CRAN team for supporting the package.

It has (once again!) been nearly two years since the last release, and a number of nice extensions, build robustifications (mostly for Windows) and fixes had been submitted over this period—see below for the three key pull requests. There are no new user-facing changes.

The most recent change, and the one triggering the change, was based on a rchk report: the one time we call Rf_eval() could conceivably have a memory allocation race so two additional PROTECT calls make it more watertight. The joys of programming with the C API …

But thanks so much to Tomas for patient help, and to Gábor for maintaining the ubuntu-rchk Docker container. While made for rhub, it is also available pre-made here at Docker Cloud which allowed me to run the rchk.sh script in a local instance.

Changes since the last release were:

Changes in RInside version 0.2.15 (2019-03-06)
  • Improved Windows build support by copying getenv("R_HOME") result and improving backslash handling in environemt variable setting (Jonathon Love in #27 and #28)

  • Improved Windows build support by quote-protecting Rscript path in Makevars.win (François-David Collin in #33)

  • A URL was corrected in README.md (Zé Vinícius in #34).

  • Temporary SEXP objects are handled more carefully at initialization to satisfy rchk (Dirk in #36)

CRANberries also provides a short report with changes from the previous release. More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page, or to issues tickets at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Justin Mason: Links for 2019-03-06

Planet Apache - Wed, 2019-03-06 18:58
  • National Climate Assessment: How to deal with despair over climate change – Vox

    The dominant narrative around climate change tells us that it’s our fault. We left the lights on too long, didn’t close the refrigerator door, and didn’t recycle our paper. I’m here to tell you that is bullshit. … Don’t give in to that shame. It’s not yours. The oil and gas industry is gaslighting you. That same IPCC report revealed that a mere 100 companies are responsible for 71 percent of global climate emissions. These people are locking you and everything you love into a tomb. You have every right to be pissed all the way off. And we have to make them hear about it.

    (tags: climate climate-change anger capitalism ipcc fossil-fuels future)

  • camelcamelcamel, a free Amazon price tracker

    ‘Our free Amazon price tracker monitors millions of products and alerts you when prices drop, helping you decide when to buy.’ Supports amazon.co.uk, handily

    (tags: amazon shopping deals buying money)

  • Why do remote meetings suck so much?

    Unstructured, “caucus”-style meetings suck particularly badly for remote workers.

    When audio/visual delays exacerbate the caucus problem for people who always get the floor in meetings, it looks to them like a new problem. It’s not new; it’s just normally experienced by people in meetings with lower caucus scores. Leadership doesn’t notice because people in leadership positions tend to have higher caucus scores, and being in a position of leadership also tends to boost your caucus score (basically because people interrupt you less). But that’s a weakness of the way we identify decision-makers: good ideas come from everywhere, and especially from people who do a lot of thinking and observing before they say anything. Making meetings more accessible to remote employees doesn’t just make meetings more accessible to remote employees; it makes meetings more accessible to everyone. 

    (tags: team meetings remote communication management caucus-score remote-work)

Categories: FLOSS Project Planets

Enrico Zini: Getting rusage of child processes on python asyncio

Planet Debian - Wed, 2019-03-06 18:00

I am writing a little application server for microservices written as compiled binaries, and I would like to log execution statistics from getrusage(2).

The application server is written using asyncio, and processes are managed using asyncio subprocesses.

Unfortunately, asyncio uses os.waitpid instead of os.wait4 to reap child processes, and to get rusage information one has to delve into the asyncio innards, and provide a custom ChildWatcher implementation. Here's how I did it:

import asyncio from asyncio.log import logger from contextlib import contextmanager import os class ExtendedResults: def __init__(self): self.rusage = None self.returncode = None class SafeChildWatcherWithRusage(asyncio.SafeChildWatcher): """ SafeChildWatcher that uses os.wait4 to also get rusage information. """ rusage_results = {} @classmethod @contextmanager def monitor(cls, proc): """ Return an ExtendedResults that gets filled when the process exits """ assert proc.pid > 0 pid = proc.pid extended_results = ExtendedResults() cls.rusage_results[pid] = extended_results try: yield extended_results finally: cls.rusage_results.pop(pid, None) def _do_waitpid(self, expected_pid): # The original is in asyncio/unix_events.py; on new python versions, it # makes sense to check changes to it and port them here assert expected_pid > 0 try: pid, status, rusage = os.wait4(expected_pid, os.WNOHANG) except ChildProcessError: # The child process is already reaped # (may happen if waitpid() is called elsewhere). pid = expected_pid returncode = 255 logger.warning( "Unknown child process pid %d, will report returncode 255", pid) else: if pid == 0: # The child process is still alive. return returncode = self._compute_returncode(status) if self._loop.get_debug(): logger.debug('process %s exited with returncode %s', expected_pid, returncode) extended_results = self.rusage_results.get(pid) if extended_results is not None: extended_results.rusage = rusage extended_results.returncode = returncode try: callback, args = self._callbacks.pop(pid) except KeyError: # pragma: no cover # May happen if .remove_child_handler() is called # after os.waitpid() returns. if self._loop.get_debug(): logger.warning("Child watcher got an unexpected pid: %r", pid, exc_info=True) else: callback(pid, returncode, *args) @classmethod def install(cls): loop = asyncio.get_event_loop() child_watcher = cls() child_watcher.attach_loop(loop) asyncio.set_child_watcher(child_watcher)

To use it:

from .hacks import SafeChildWatcherWithRusage SafeChildWatcherWithRusage.install() ... @coroutine def run(self, *args, **kw): kw["stdin"] = asyncio.subprocess.PIPE kw["stdout"] = asyncio.subprocess.PIPE kw["stderr"] = asyncio.subprocess.PIPE self.started = time.time() self.proc = yield from asyncio.create_subprocess_exec(*args, **kw) from .hacks import SafeChildWatcherWithRusage with SafeChildWatcherWithRusage.monitor(self.proc) as results: yield from asyncio.tasks.gather( self.write_stdin(self.proc.stdin), self.read_stdout(self.proc.stdout), self.read_stderr(self.proc.stderr) ) self.returncode = yield from self.proc.wait() self.rusage = results.rusage self.ended = time.time()
Categories: FLOSS Project Planets

More on Headerbars: Rebuttals

Planet KDE - Wed, 2019-03-06 17:54

Folks offered a lot of feedback on my article on headerbars last year, some of which was skeptical or critical. I’d like to address some of the arguments people made in this follow-up:

It doesn’t really matter that there’s less visible or actual window drag space

People pointed out that you can drag on the UI controls, or use the hidden Alt-drag shortcut. Other people questioned how useful it is to drag windows around anyway, preferring to maximize everything or use window tiling keyboard shortcuts. I will address these responses:

“Just drag on the controls in the headerbar”

First of all, dragging controls to drag the window isn’t very intuitive. What other controls outside the headerbar allow you to move the window when dragging on them? Sure, you can learn it, but this isn’t the same as a good user interface that re-uses familiarity with existing elements rather than making you learn new modes.

Second, you can’t drag the window by dragging on controls that themselves implement draggable behaviors–such as tab bars, comboboxes, pop-up menus, and sliders. So those controls can’t be put on the headerbar without reducing the drag area and violating the “you can drag the window by dragging on the controls” rule. In the original post, I gave an example of Firefox’s horrendous CSD that puts draggable tabs in the headerbar, reducing the drag area for the window itself to almost nothing. Ensuring draggability by only using controls that are not themselves draggable reduces developer flexibility compared to a traditional titlebar. It’s just not a problem if you have a separate titlebar.

“Just alt-drag the window or move it with keyboard shortcuts”

This somewhat flippant answer describes a workaround, not a general-purpose solution for everyone. Most users drag their windows around all the time and probably don’t know any of those shortcuts. For them, adequate window draggability is important–especially if your desktop happens to be targeting these people as the #1 user group.

“Just maximize the window and then there’s plenty of visible drag space on the headerbar”

it depends on the implementation (e.g. Firefox’s CSD is perfectly capable of having almost no drag space when maximized), but this is broadly true. However, what if you’re not the kind of user who maximizes all of their windows? In any event, window draggability is least important for maximized windows. The whole point of dragging a window around is to move it somewhere else, which requires that it be smaller than the area in which it’s moved.

Taken together, these issues demonstrate that reduced draggability reduces developer flexibility and can be a real problem. It can’t just be dismissed as much ado about nothing.

You don’t need menubars anyway

A lot of people expressed many variants of this argument:

“You don’t need menubars anymore because actions and commands can be located inline, available contextually”

This works, but imposes a high bar in UI design, and results in frustrating and awkward software when implemented by a team without at least one person with A+ UI design skills who everyone else actually listens to. This approach is also very labor-intensive and bug-prone as by definition it’s custom-made for each app and requires a lot of code. It may not scale well for content with many actions you can perform on it, since there’s a limited amount of space in the content view to put contextual actions. It furthermore throws away users’ existing familiarity and muscle memory; for example when cut/copy/paste/find are always available in the same place in the Edit menu, users never need to re-learn how to cut, copy, and paste, and find text in each app. Finally, this approach doesn’t help the user learn keyboard shortcuts.

So yes, this approach works, but results in significant drawbacks. It’s definitely not a 100% slam-dunk superior user interface.

“Menubars are overkill for simple apps”

This is a reasonable argument. Most of the items in the average menu bar pertain to text manipulation, file handling, and view adjustment. An app that doesn’t have any text manipulation or file handling can probably get away with putting what’s left in toolbar buttons. In fact KDE’s Discover already does this, for just those reasons. A number of other simple mouse-centric KDE apps like the games could probably do the same.

But the thing is, you don’t need to implement a CSD headerbar to get rid of your menubar! You can do it with a traditional toolbar and a traditional titlebar, and gain all the advantages of those individual user interface elements: guaranteed space to drag the window, a legible window title, a user-customizable toolbar that can include draggable UI elements, and so on. No need to throw the baby out with the bathwater.

“Menubars don’t exist on mobile and mobile is the future therefore we need to get rid of them on the desktop or else people under 25 will perceive us as stogy old farts and won’t want to use our apps”

I see no evidence that the under-25 crowd hates desktop apps with menubars. A lot of KDE’s most active members are young, and all fully understand the productivity benefits of real desktop apps with traditional user interfaces.

The truth is, mobile phones are really only good for communication, travel, controlling portable hardware (cameras, drones, etc) and content consumption that doesn’t benefit from a large screen. Other than these use cases, mobile apps are universally worse to use than traditional desktop apps–especially for productivity. They are slower, more awkward, have fewer features, take longer to accomplish the same tasks, are harder to multi-task with, have user interfaces that are constantly in a state of flux, and are an absolute nightmare for anything that requires precise text manipulation or formatting.

Most of these limitations are imposed by the hardware’s own input and output capabilities. This means that the only way to improve the situation is to plug in a big screen and some faster, more precise input devices–essentially turning the mobile device into an underpowered desktop computer. Not coincidentally, KDE’s Kirigami user interface toolkit explicitly supports this use case anyway.

I think Star Trek nailed the ideal mobile/desktop split decades ago: people use their mobile devices for communication, information gathering, and relaxing, but when they need to be productive, they use the huge desktop-computer-style consoles built into the walls of their ships. The bigger devices offer speed, power, precision, and good multi-tasking. When you need to get something important done, those are more important features than being able to have the device in your pocket or purse all the time.

The lesson is clear: portable mobile devices are for convenience, not productivity. Mobile isn’t going to kill the desktop any more than air freight killed rail freight. They’re just for different things.

“Menubars are old and clunky and clumsy and obsolete and a relic of the past”

If this is true, why haven’t we come with anything better yet after more than two decades of user interface experimentation?

  • MS Office style Ribbons take up much more space than the combination of a menubar and toolbar they replace, make it harder to find what you’re looking for when the context sensitivity feature isn’t implemented perfectly, and don’t teach the user keyboard shortcuts.
  • Hamburger menus in the toolbar have to leave out most functionality or else they become too cluttered. Most also don’t make any effort to teach the user keyboard shortcuts.
  • Action drawers that slide in from the left or right are basically just hamburger menus, with all the same drawbacks.
  • Inline controls were already addressed above.

I have yet to encounter a feature-rich, high-functionality desktop app that completely does away with the concept of the main menubar without feeling awkward, crippled, slow, or like something has been left out. I’m sure someday we will kill the menubar after we’ve invented something genuinely better that doesn’t feel like a regression in any way, but we’re not there yet.

And in the meantime, you don’t declare something to be dead before you’ve actually killed it.

The menubar isn’t dead yet for desktop apps because we haven’t yet come up with anything that’s universally better. The GTK & GNOME approach has a hamburger menu on the toolbar that holds global controls, coupled with a limited number of inline editing controls. most of which are only available via a hidden UI (the right-click context menu or undiscoverable keyboard shortcuts). This is not a solution, it’s a regression: many features must be removed or hidden to make it not visually overwhelming; the inline controls are invisible unless you think to right-click everywhere; and it’s impossible to learn keyboard shortcuts at the moment of use. This is a steep price to pay for visual cleanliness and approachability.

Displaying a title is an application-specific issue

Only when there’s no titlebar.

When the window manager guarantees your window a titlebar, app developers don’t have to reinvent the wheel by implementing custom labels to solve the same problem over and over again; they just set the title appropriately and move on.

Iff you implement a headerbar but want to put a title in it, it competes for space with the rest of the items in the headerbar. That means it can’t be very long unless your app has almost no UI controls exposed on the headerbar, which is a problem for any application that could benefit from showing a long title–like web browsers, where the titlebar has traditionally showed the website’s title (imagine that).

When you use a traditional discrete titlebar, you don’t have any of these challenges to solve, so you can focus on more important parts of your app.

Headerbars were meant for simple apps; it’s okay for complicated professional apps to not use them

Some people defend headerbars by arguing that the menubar is obsolete, then say that complicated apps can and should still have menubars. This doesn’t work: either menus are obsolete, or they aren’t. If they aren’t, then removing them is a mistake.

The better argument is that headerbars are only intended for very simple apps that don’t really benefit much from a menubar anyway because most of the default entries are inapplicable and would be disabled placeholders. I already acknowledged that it’s probably fine to remove the menubar for very simple apps that don’t have selectable text or do any file handling. But as I mentioned before, there’s no reason why you need to implement a CSD headerbar if your app doesn’t have a menubar.

It’s KDE’s fault for not supporting client-side decorations properly, so nobody should avoid them just to work around KDE brokenness

There is a kernel of truth here: KDE developers have indeed opted not to support GTK client-side decorations as they are currently implemented.

However, this is only because that implementation utilizes Motif Window Hints from the Motif Window Manager, which are not a part of the cross-desktop specs for X11 window managers (ICCCM and EMWH) that until that point everyone had conformed to. KDE Plasma’s KWin window manager strictly follows these cross-desktop standards in order to be a good citizen, and may of its architectural design decisions reflect the specs.

GTK’s headerbars violate this standard, and adding support for the non-spec-following Motif-based GTK CSDs would require significant changes to KWin’s codebase that were judged to present substantial risk of breakage, and make KWin itself no longer a standards-compliant X11 window manager in any event.

At this point, GTK developers may be thinking, “Well, that’s not my problem that you wrote KWin in such an inflexible way.” But that doesn’t fly: you can’t violate a cross-desktop spec and then blame other people for not supporting your nonstandard stuff because they instead decided to do the right thing by following the spec.

There are rumblings of being able to support GTK CSDs in Wayland. For now though, the situation on X11 is unfortunate but pretty much unavoidable. You can’t break a spec and then ask everyone else to support your brokenness; it defeats the entire purpose of having a spec in the first place.

Anyone interested in more of the technical details can read through the comments in the following bug reports:

https://bugs.kde.org/show_bug.cgi?id=379637

https://bugzilla.gnome.org/show_bug.cgi?id=csd

https://gitlab.gnome.org/GNOME/gtk/issues/499

https://gitlab.gnome.org/GNOME/gtk/issues/489

https://gitlab.gnome.org/GNOME/gtk/issues/215

https://gitlab.gnome.org/GNOME/gtk/issues/488

The bottom line is that it’s not fair to blame KWin and its developers for not supporting the GTK developers’ decision to implement client-side decorations without extending the X11 window manager spec so that everybody could follow it.

I hope this post helps to clarify my position on CSDs. I suspect that these rebuttals won’t put the issue to rest because CSD headerbars have always been more about aesthetics and vertical space savings than functionality, power, and flexibility. That’s fine! all of these arguments I’m making are sort of a roundabout way of saying that I prefer the latter traits to the former ones. I think it’s a good thing that we have choice in the desktop space–real choice, where well-implemented competing visions and design goals appeal to different sorts of people. And that’s what we’re all doing here: empowering people to find what works best for them so their needs and desires can be provided by high-quality open-source software that respects their privacy, freedom, and need for highly usable and productive applications.

Categories: FLOSS Project Planets

Lullabot: Lullabot Education Becomes Osio Labs

Planet Drupal - Wed, 2019-03-06 15:54

What do you do when you accomplish your dream? If you’re like Addison Berry, you make another dream.

Categories: FLOSS Project Planets

Pages